Re: Retrying Channel Status?
I've run into the same situation before, and it turned out to be Message (BSequence Error. (BIf the channel starts fine and it stops when the first message is sent, it (Bis most probably (Bcaused by that error. (B (BYou can resolve the situation by stopping the channel manually and issuing (BReset Channel (Bcommand. (B (BAs Tim.A said, I suggest you look into the AMQERR0X.log file. (B (BShinichi Takahashi (B- - - - - - - - - - - - - - - - (BInternet Systems, IBM Japan Systems Engineering (ISE) (B1-1 Nakase, Mihama-ku, Chiba City, Chiba, Japan 261-8522 (Be-mail: [EMAIL PROTECTED] (BPhone: $B!\ (B81-43-297-5973 Ex.1804-5973 (B (B (B (B (B Tim Armstrong (B <[EMAIL PROTECTED]To: [EMAIL PROTECTED] (B OM> cc: (B Sent by: MQSeriesSubject: Re: Retrying Channel Status? (B List (B (B (B (B 2002/11/21 10:57 (B Please respond to (B MQSeries List (B (B (B (B (B (BCheck the latest MQ error logs. (B (BOn Win2K (BAMQERR01.log in the following directories assuming installed on drive C. (B (BC:\Program Files\IBM\Websphere MQ\errors (BC:\program Files\IBM\Webshpere MQ\qmgrs\@SYSTEM\errors (BC:\program Files\IBM\Webshpere MQ\qmgrs\\errors (B (BOn your AS/400. Note these are from the 5.3 manual but should still be (Bvalid for 5.2. I hope :) (B (B/QIBM/UserData/mqm//errors (B/QIBM/UserData/mqm/&SYSTEM/errors (B (BRegards (BTim A (B (B (B (B (B (B "Pope, Ben" (B cc: (B Sent by: MQSeriesSubject: Retrying Channel (BStatus? (B List (B (B (B (B 21/11/2002 12:17 (B Please respond to (B MQSeries List (B (B (B (B (B (B (B (B (BI've got a situation between an Win2K (5.3) and AS/400 (5.2) box with a (Bsender channel stuck (Bin retrying mode. If I manually stop the channel I can ping it (Bsuccessfully. Initially, I could even (Bmanually start it and it appeared to be running fine. As soon as a message (Blanded in the (Btransmission queue, however, the channel status switched over to retrying. (B (B (BConsidering I can ping the channel O.K. leads me to believe both end points (Bare defined (Bcorrectly. I checked the message in the transmission queue and it appears (Bto have a valid (Btransmission header prepended. Any suggestions on what might cause this (Bbehavior or (Bwhere to look for more clues? (B (B (BThanks, Ben (B (BInstructions for managing your mailing list subscription are provided in (Bthe Listserv General Users Guide available at http://www.lsoft.com (BArchive: http://vm.akh-wien.ac.at/MQSeries.archive (B (BInstructions for managing your mailing list subscription are provided in (Bthe Listserv General Users Guide available at http://www.lsoft.com (BArchive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Convert a message to a single readable "string" in WMQI
Could also put it in a CDATA section as a CData section can contains XML without it being parsed. SET OutputRoot.XML.WmqiDiagnostic.OriginalMessage.(XML.CDataSection) = InputRoot.XML Regards Tim A John Scott cc: Sent by: MQSeriesSubject: Convert a message to a single readable "string" in WMQI List 21/11/2002 02:33 Please respond to MQSeries List In WMQI if I want to create a diagnostic message in a compute node such as: OutputRoot.XML.WmqiDiagnostic.OriginalExceptionList = InputExceptionList OutputRoot.XML.WmqiDiagnostic.OriginalMessage = InputRoot.<> How can I cast the whole message body as a single string? If I reset the content descriptor to a BLOB, and use plain "InputRoot", then I get the original message as hex which is not readable. I want the original message, but in a more readable format (marked up with & etc.) Is there any way of reliably doing this, without knowing what the input message is going to look like (they might send me garbage). I don't want my diagnostic recording sub-flow from blowing up because of a garbaged message (e.g. invalid XML such as ""). I would be happy for this to be marked up in XML to "<..." as this would display OK in something like an Internet Explorer... Regards John. ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in youe e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Retrying Channel Status?
Check the latest MQ error logs. On Win2K AMQERR01.log in the following directories assuming installed on drive C. C:\Program Files\IBM\Websphere MQ\errors C:\program Files\IBM\Webshpere MQ\qmgrs\@SYSTEM\errors C:\program Files\IBM\Webshpere MQ\qmgrs\\errors On your AS/400. Note these are from the 5.3 manual but should still be valid for 5.2. I hope :) /QIBM/UserData/mqm//errors /QIBM/UserData/mqm/&SYSTEM/errors Regards Tim A "Pope, Ben" cc: Sent by: MQSeriesSubject: Retrying Channel Status? List 21/11/2002 12:17 Please respond to MQSeries List I've got a situation between an Win2K (5.3) and AS/400 (5.2) box with a sender channel stuck in retrying mode. If I manually stop the channel I can ping it successfully. Initially, I could even manually start it and it appeared to be running fine. As soon as a message landed in the transmission queue, however, the channel status switched over to retrying. Considering I can ping the channel O.K. leads me to believe both end points are defined correctly. I checked the message in the transmission queue and it appears to have a valid transmission header prepended. Any suggestions on what might cause this behavior or where to look for more clues? 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
Retrying Channel Status?
Title: Retrying Channel Status? I've got a situation between an Win2K (5.3) and AS/400 (5.2) box with a sender channel stuck in retrying mode. If I manually stop the channel I can ping it successfully. Initially, I could even manually start it and it appeared to be running fine. As soon as a message landed in the transmission queue, however, the channel status switched over to retrying. Considering I can ping the channel O.K. leads me to believe both end points are defined correctly. I checked the message in the transmission queue and it appears to have a valid transmission header prepended. Any suggestions on what might cause this behavior or where to look for more clues? Thanks, Ben
MQ5.3 Client -- Not reconnecting once Qmanager Starts
Title: MQ5.3 Client -- Not reconnecting once Qmanager Starts List, Thanks so much for these suggestions. But, now that the vendor I'm working with has gotten his services to successfully disconnect from my QManager during a QMangager Shutdown, they are having trouble reconnecting to the QManager, when it and the listener successfully start, without stopping and starting there application manually. Is there something that I may have missed as an admin in setting up the client channels? They are using the mqax200.dll. Again what strikes me as being particularly odd is that a manual recycle of the application fixes the problem. The client is on Win2k and the QManager is on a different Win2k machine. Oh, what I continually see in the log is a TCPIP error message. Its almost like the operating system is not releasing the client connection although the client code does issue the disconnect. A configuration error for TCP/IP occurred. Error in configuration for communications to host ''. Allocation of a TCP/IP conversation to host '' was not possible. The configuration error may be one of the following: &N &B 1.If the communications protocol is LU 6.2, it may be that one of the transmission parameters (Mode, or TP Name) is incorrect. Correct the error and try again. The mode name should be the same as the mode defined on host ''. The TP name on '' should be defined. &N &B 2.If the communications protocol is LU 6.2, it may be that an LU 6.2 session has not been established. Contact your systems administrator. &N &B 3.If the communications protocol is TCP/IP, it may be that the host name specified is incorrect. Correct the error and try again. &N &B 4.If the communications protocol is TCP/IP, it may be that the host name specified cannot be resolved to a network address. The host name may not be in the nameserver. &P The return code from the TCP/IP (connect) call was 10049 (X'2741'). &P Record the error values and tell the system administrator. In advance thanks for any advice. Joe -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 12, 2002 9:10 AM To: [EMAIL PROTECTED] Subject: Re: MQ5.3 Client -- Stop of Qmanager Hanging This could be the result of the age ole dilemma: "How do you get somebody to go who want to stay, and how do you get somebody to stay who wants to leave' Your Client must give the QMGR the chance to end him if the QMGR is asked to leave. add FAIL_IF_QUIESCING to ALL your options where applicipal. Also if your client is pounding at the door repeatedly after the QMGR comes down to get back in. It may cause a problem with started amqscrsta's in bringing up the QMGR. Usually a work around is to turn off the executable permission on amqscrsta_nd in opt/mqm/bin and restart the QMGR. Then switch the bit back on. This last bit of stuff IBM sez it is functioning as expected. I believe IBM was lazy on this one They should fix it. runmqlsr is an option but it starts acting funky at around 500+ connections. bobbee >From: "DeBlassio, Joe" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQ5.3 Client -- Stop of Qmanager Hanging >Date: Mon, 11 Nov 2002 16:36:10 -0500 > > >I am working with a vendor consultant that has developed an application >using the MQSeries Client. The client application is running on a Win2k >Server and the Server Qmanager is running on a different Win2k Server. Of >course the client application connects to and uses the Server Qmanager. > >When I began testing I noticed something that was of concern and I hope to >draw from others experiences with the Client. I'm not very familiar with >the client so forgive me if this seems basic. > >When I issue an endmqm on the Qmanager that the client is connected to, the >Qmanager does not want to completely shutdown. When I spoke with the >consultant they informed me that there application was in fact detecting >that the Qmanager was quiesing (2161) and that the Qmanager was unavailable >(2059). Even though they had detected these codes, my Server Qmanager >would >not end, even after issuing a preemptive shutdown. > >Is there something that the consultant may have overlooked that I can >suggest? I've already suggested that they make sure they are issuing a >disconnect. Or is there something I missed in setting up the client >channel >table? I also noticed that the Server Qmanager does shutdown when I >physically terminate there MQ Client application. > >Also, thanks so much for the tips on the 2009 and 2016 Return Codes. I >will >definitely put that information to good use before signing off on this >vendors MQ Client developed application. > >Any other tips of things to watch out for from vendor developed MQ Clients >would be appreciated. > >Thanks so much, > >Joe > > > > __
Re: CSQUDLQH
Can you send me a copy. This program does not exist in any of my MQ
Series libraries.
Thank You
>>> [EMAIL PROTECTED] 11/20/02 04:50PM >>>
It's placed in your SCSQLOAD tlib by the SMP/E install.
Mark Steely
cc:
Sent by: MQSeriesSubject: CSQUDLQH
List
11/20/2002 04:30
PM
Please respond to
MQSeries List
We are OS/390 V2.8 and MQ Series V2.1. The MQ Series group is looking
for a way on the mainframe to re-process the dead letter queue. We
found
a sample job executing pgm CSQUDLQH. Where is this program? Here is
the
sample JCL:
//READQ EXEC PGM=CSQUDLQH,
// PARM='CSQ1.DEAD.QUEUE CSQ1'
//STEPLIB DD DSN=SYS2.LINKLIB,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQAUTH,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSIN DD *
INPUTQM(CSQ2) INPUTQ('CSQ2.DEAD.QUEUE')
ACTION(RETRY)
//
Any help would be appreciated.
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
Re: CSQUDLQH
It's placed in your SCSQLOAD tlib by the SMP/E install.
Mark Steely
cc:
Sent by: MQSeriesSubject: CSQUDLQH
List
11/20/2002 04:30
PM
Please respond to
MQSeries List
We are OS/390 V2.8 and MQ Series V2.1. The MQ Series group is looking
for a way on the mainframe to re-process the dead letter queue. We
found
a sample job executing pgm CSQUDLQH. Where is this program? Here is
the
sample JCL:
//READQ EXEC PGM=CSQUDLQH,
// PARM='CSQ1.DEAD.QUEUE CSQ1'
//STEPLIB DD DSN=SYS2.LINKLIB,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQAUTH,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSIN DD *
INPUTQM(CSQ2) INPUTQ('CSQ2.DEAD.QUEUE')
ACTION(RETRY)
//
Any help would be appreciated.
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
CSQUDLQH
We are OS/390 V2.8 and MQ Series V2.1. The MQ Series group is looking
for a way on the mainframe to re-process the dead letter queue. We found
a sample job executing pgm CSQUDLQH. Where is this program? Here is the
sample JCL:
//READQ EXEC PGM=CSQUDLQH,
// PARM='CSQ1.DEAD.QUEUE CSQ1'
//STEPLIB DD DSN=SYS2.LINKLIB,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQANLE,DISP=SHR
// DD DSN=MQSERIES.SCSQAUTH,DISP=SHR
//SYSOUT DD SYSOUT=*
//SYSIN DD *
INPUTQM(CSQ2) INPUTQ('CSQ2.DEAD.QUEUE')
ACTION(RETRY)
//
Any help would be appreciated.
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
Re: MQ5.3 Client -- Stop of Qmanager Hanging
Make sure the application is not caching the connection handle and trying to reuse it when a failure occurs. "DeBlassio, Joe" cc: Sent by: MQSeriesSubject: Re: MQ5.3 Client -- Stop of Qmanager Hanging List <[EMAIL PROTECTED] C.AT> 11/20/2002 02:08 PM Please respond to MQSeries List List, Thanks so much for these suggestions. But, now that the vendor I'm working with has gotten his services to successfully disconnect from my QManager during a QMangager Shutdown, they are having trouble reconnecting to the QManager, when it and the listener successfully start, without stopping and starting there application manually. Is there something that I may have missed as an admin in setting up the client channels? Oh, what I continually see in the log is a TCPIP error message A configuration error for TCP/IP occurred. Error in configuration for communications to host ''. Allocation of a TCP/IP conversation to host '' was not possible. The configuration error may be one of the following: &N &B 1.If the communications protocol is LU 6.2, it may be that one of the transmission parameters (Mode, or TP Name) is incorrect. Correct the error and try again. The mode name should be the same as the mode defined on host ''. The TP name on '' should be defined. &N &B 2.If the communications protocol is LU 6.2, it may be that an LU 6.2 session has not been established. Contact your systems administrator. &N &B 3.If the communications protocol is TCP/IP, it may be that the host name specified is incorrect. Correct the error and try again. &N &B 4.If the communications protocol is TCP/IP, it may be that the host name specified cannot be resolved to a network address. The host name may not be in the nameserver. &P The return code from the TCP/IP (connect) call was 10049 (X'2741'). &P Record the error values and tell the system administrator. Again what strikes me as being particularly odd is that a manual recycle of the application fixes the problem. In advance thanks for any advice. Joe -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 12, 2002 9:10 AM To: [EMAIL PROTECTED] Subject: Re: MQ5.3 Client -- Stop of Qmanager Hanging This could be the result of the age ole dilemma: "How do you get somebody to go who want to stay, and how do you get somebody to stay who wants to leave' Your Client must give the QMGR the chance to end him if the QMGR is asked to leave. add FAIL_IF_QUIESCING to ALL your options where applicipal. Also if your client is pounding at the door repeatedly after the QMGR comes down to get back in. It may cause a problem with started amqscrsta's in bringing up the QMGR. Usually a work around is to turn off the executable permission on amqscrsta_nd in opt/mqm/bin and restart the QMGR. Then switch the bit back on. This last bit of stuff IBM sez it is functioning as expected. I believe IBM was lazy on this one They should fix it. runmqlsr is an option but it starts acting funky at around 500+ connections. bobbee >From: "DeBlassio, Joe" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQ5.3 Client -- Stop of Qmanager Hanging >Date: Mon, 11 Nov 2002 16:36:10 -0500 > > >I am working with a vendor consultant that has developed an application >using the MQSeries Client. The client application is running on a Win2k >Server and the Server Qmanager is running on a different Win2k Server. Of >course the client application connects to and uses the Server Qmanager. > >When I began testing I noticed something that was of concern and I hope to >draw from others experiences with the Client. I'm not very familiar with >the client so forgive me if this seems basic. > >When I issue an endmqm on the Qmanager that the client is connected to, the >Qmanager does not want to completely shutdown. When I spoke with the >consultant they informed me that there application was in fact detecting >that the Qmanager was quiesing (2161) and that the Qmanager was unavailable >(2059). Even though they had detected these codes, my Server Qmanager >would >not end, even after issuing a preemptive shutdown. > >Is there something that the consultant may have overlooked that I can >suggest? I've already suggested that they make sure they are issuing a >disconnect. Or is there something I missed in setting up the client >channel >table? I also noticed that the Server Qmanager does shutdown when I >physically terminate there MQ Client application. > >Also, thanks so much for the tips on the 2009 and 2016 Return Codes. I >will >definitely put that information to good use before signing off on this >vendors MQ Client developed applicati
Re: Vulnerabilities for Client Concentrator Model
Eventually the XMIT queue for the Remote Queue would fill up and ALL application putting to that box through that XMIT queue would come to a grinding halt From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Vulnerabilities for Client Concentrator Model Date: Wed, 20 Nov 2002 14:06:58 -0500 The channel I was talking about was the one from my HUB QM to the Concentrator QM. If messages coming in from the HUB were landing on a local queue on the concentrator, and that queue filled up, and then the DLQ filled up, then the channel from the HUB to the Concentrator would go down. In this case, putting apps on remote queue managers would still be putting messages without any errors, yet none of their messages could make it to the concentrator, all because of AppA. Sorry I wasn't more clear originally. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: Vulnerabilities for Client Concentrator Model Peter, I am not sure if the CLient Channel will go down because a Queue is at the 'brim'. This would be the effect in a server channel. In a client channel the app would receive an error message back with a reurn code. Also, items normally/only go to the DLQ when there is no connected app to which MQ can return a RC. In your case the client would get the RC. In a server to server connection the app is long gone so the message goes to the DLQ. bobbee >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Vulnerabilities for Client Concentrator Model >Date: Wed, 20 Nov 2002 12:58:19 -0500 > >If you have 100 apps all client connected to a central MQ server, what are >the various ways that AppA can negatively effect AppB? > >For instance, AppA's input queue from the outside world fills up, because >app A is down. Now the MCA starts putting the messages to the DLQ, and it >fills up. Now the channel to the outside world goes down, and everyone is >effected. > >What else can happen? > > > > > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > > >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 _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive 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 _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SECURITY ISSUES ON MQ QUEUE
If you look in the syslog, scan from the bottom, there will be a message describing the violation. Give this to the RACF security person. it explains what he needs to set rules on. Try searching on 'MQQUEUE'. But off the top of my head you need access to I believe at least 3 resources to do what you are doing/ It has been awhile and I don't have the doc anymore otherwise I would give it to you. I do remember the syslog contained all the information. bobbee From: Middleware Group Mailbox <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: SECURITY ISSUES ON MQ QUEUE Date: Wed, 20 Nov 2002 14:35:10 -0500 In the real RACF definitions ther is no blank after MQD6. Regards, Mohamed. -Original Message- From: Doug Jenkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:44 PM To: [EMAIL PROTECTED] Subject: Re: SECURITY ISSUES ON MQ QUEUE Mohamed, Your racf definitions each have a blank after the MQD6. If this is indeed how the definitions are written, I suspect that is your problem. Instead of: PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) You should have PERMIT MQD6.SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) Cheers, Doug Middleware Group MailboxTo: [EMAIL PROTECTED] Subject: SECURITY ISSUES ON MQ QUEUE 11/20/2002 01:22 PM Please respond to MQSeries List ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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 _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Vulnerabilities for Client Concentrator Model
We have several applications sharing concentrators, and so far the apps haven't caused any problems for each other. If you use multi-threaded agents, there's a possibility that if one thread breaks, the whole agent will come down. Since the code that runs on the server is IBM's, we think the risks are worth taking. So we do use multi-threaded agents. If messages from both AppA and AppB need to send messages that will go to the same server, their messages will use the same transmit queue and channel. If one app has really large messages, it can block the other app's messages. We define a second pair of channels that we use for big messages, or for bulk loads of messages. You have to work with the developers to identify the queues and keep them separate, though. "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] Subject: Vulnerabilities for Client Concentrator Model Sent by: MQSeries List 11/20/2002 11:58 AM Please respond to MQSeries List If you have 100 apps all client connected to a central MQ server, what are the various ways that AppA can negatively effect AppB? For instance, AppA's input queue from the outside world fills up, because app A is down. Now the MCA starts putting the messages to the DLQ, and it fills up. Now the channel to the outside world goes down, and everyone is effected. What else can happen? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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: Vulnerabilities for Client Concentrator Model
Good stuff. In particular, I am looking for things that cannot be avoided admistrativly. For instance, there is no way to keep AppA from putting millions of messages and never committing, which then effects everybody else's ability to syncpoint. No Admin solution here, right? If we leave the max queue depth at 5000 and the max message size at 4 MEG, one app can stuff a queue with 4 meg messages and stop the party for everyone cause the disk is full. (So the argument here is get a huge hard drive and/or tune each queue specifically for max messages / depth?) Orphaned channels caused by a flaky app (AppA) can cause you to hit your limit, and keep AppB from connecting. I don't see any solution here. Apps reading each other's queues can be solved via built in security. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Re: Vulnerabilities for Client Concentrator Model Peter, Well, since you are running clients, I am assuming that you are also using syncpoint. You may run into the max uncommitted messages limitation. Even if you don't run into max uncommitted messages problems, a large number of uncommitted messages could overrun a circular log. Be sure syncpoint latency is minimized (i.e. commit as soon as possible) and/or specify generous log sizes. If the channels get orphaned by network problems or badly behaved clients, you may hit your max channels limit. Depending on message size and latency, you can fill up your underlying file system long before you max out your queue depth. That's reaching a bit though. Depending on your authorization model, AppA can potentially read/write AppB's queues. That's all that comes immediately to mind. -- T.Rob -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 12:58 PM To: [EMAIL PROTECTED] Subject: Vulnerabilities for Client Concentrator Model If you have 100 apps all client connected to a central MQ server, what are the various ways that AppA can negatively effect AppB? For instance, AppA's input queue from the outside world fills up, because app A is down. Now the MCA starts putting the messages to the DLQ, and it fills up. Now the channel to the outside world goes down, and everyone is effected. What else can happen? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQMQ MsgID - valid characters
You should not pass the msgid in XML without converting it to a string first. You could do like JMS and convert each half-byte to the single text character used in hex notation, i.e. "0"-"F". Of course, msgid is then transported in 48 bytes, which needs to be reversed at the other end. > -Original Message- > From: Pope, Ben [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, November 20, 2002 8:36 AM > To: [EMAIL PROTECTED] > Subject: MQMQ MsgID - valid characters > > > I have a situation where I need to pass the MsgId contents as part of an > XML message. > What I've found in the docs describes how the field in constructed by the > queue manger > but it is described as being simply "a byte field". Are there any details > as to what byte > range could be used? Specifically, codes between 0x00 and 0x20 are > considered invalid > XML and if they can be included in the MsgId field then I need to account > for that > possibility. > > 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: SECURITY ISSUES ON MQ QUEUE
In the real RACF definitions ther is no blank after MQD6. Regards, Mohamed. -Original Message- From: Doug Jenkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:44 PM To: [EMAIL PROTECTED] Subject: Re: SECURITY ISSUES ON MQ QUEUE Mohamed, Your racf definitions each have a blank after the MQD6. If this is indeed how the definitions are written, I suspect that is your problem. Instead of: PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) You should have PERMIT MQD6.SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) Cheers, Doug Middleware Group MailboxTo: [EMAIL PROTECTED] Subject: SECURITY ISSUES ON MQ QUEUE 11/20/2002 01:22 PM Please respond to MQSeries List ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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: Vulnerabilities for Client Concentrator Model
Peter, Well, since you are running clients, I am assuming that you are also using syncpoint. You may run into the max uncommitted messages limitation. Even if you don't run into max uncommitted messages problems, a large number of uncommitted messages could overrun a circular log. Be sure syncpoint latency is minimized (i.e. commit as soon as possible) and/or specify generous log sizes. If the channels get orphaned by network problems or badly behaved clients, you may hit your max channels limit. Depending on message size and latency, you can fill up your underlying file system long before you max out your queue depth. That's reaching a bit though. Depending on your authorization model, AppA can potentially read/write AppB's queues. That's all that comes immediately to mind. -- T.Rob -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 12:58 PM To: [EMAIL PROTECTED] Subject: Vulnerabilities for Client Concentrator Model If you have 100 apps all client connected to a central MQ server, what are the various ways that AppA can negatively effect AppB? For instance, AppA's input queue from the outside world fills up, because app A is down. Now the MCA starts putting the messages to the DLQ, and it fills up. Now the channel to the outside world goes down, and everyone is effected. What else can happen? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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: MQ5.3 Client -- Stop of Qmanager Hanging
Title: RE: MQ5.3 Client -- Stop of Qmanager Hanging List, Thanks so much for these suggestions. But, now that the vendor I'm working with has gotten his services to successfully disconnect from my QManager during a QMangager Shutdown, they are having trouble reconnecting to the QManager, when it and the listener successfully start, without stopping and starting there application manually. Is there something that I may have missed as an admin in setting up the client channels? Oh, what I continually see in the log is a TCPIP error message A configuration error for TCP/IP occurred. Error in configuration for communications to host ''. Allocation of a TCP/IP conversation to host '' was not possible. The configuration error may be one of the following: &N &B 1.If the communications protocol is LU 6.2, it may be that one of the transmission parameters (Mode, or TP Name) is incorrect. Correct the error and try again. The mode name should be the same as the mode defined on host ''. The TP name on '' should be defined. &N &B 2.If the communications protocol is LU 6.2, it may be that an LU 6.2 session has not been established. Contact your systems administrator. &N &B 3.If the communications protocol is TCP/IP, it may be that the host name specified is incorrect. Correct the error and try again. &N &B 4.If the communications protocol is TCP/IP, it may be that the host name specified cannot be resolved to a network address. The host name may not be in the nameserver. &P The return code from the TCP/IP (connect) call was 10049 (X'2741'). &P Record the error values and tell the system administrator. Again what strikes me as being particularly odd is that a manual recycle of the application fixes the problem. In advance thanks for any advice. Joe -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 12, 2002 9:10 AM To: [EMAIL PROTECTED] Subject: Re: MQ5.3 Client -- Stop of Qmanager Hanging This could be the result of the age ole dilemma: "How do you get somebody to go who want to stay, and how do you get somebody to stay who wants to leave' Your Client must give the QMGR the chance to end him if the QMGR is asked to leave. add FAIL_IF_QUIESCING to ALL your options where applicipal. Also if your client is pounding at the door repeatedly after the QMGR comes down to get back in. It may cause a problem with started amqscrsta's in bringing up the QMGR. Usually a work around is to turn off the executable permission on amqscrsta_nd in opt/mqm/bin and restart the QMGR. Then switch the bit back on. This last bit of stuff IBM sez it is functioning as expected. I believe IBM was lazy on this one They should fix it. runmqlsr is an option but it starts acting funky at around 500+ connections. bobbee >From: "DeBlassio, Joe" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: MQ5.3 Client -- Stop of Qmanager Hanging >Date: Mon, 11 Nov 2002 16:36:10 -0500 > > >I am working with a vendor consultant that has developed an application >using the MQSeries Client. The client application is running on a Win2k >Server and the Server Qmanager is running on a different Win2k Server. Of >course the client application connects to and uses the Server Qmanager. > >When I began testing I noticed something that was of concern and I hope to >draw from others experiences with the Client. I'm not very familiar with >the client so forgive me if this seems basic. > >When I issue an endmqm on the Qmanager that the client is connected to, the >Qmanager does not want to completely shutdown. When I spoke with the >consultant they informed me that there application was in fact detecting >that the Qmanager was quiesing (2161) and that the Qmanager was unavailable >(2059). Even though they had detected these codes, my Server Qmanager >would >not end, even after issuing a preemptive shutdown. > >Is there something that the consultant may have overlooked that I can >suggest? I've already suggested that they make sure they are issuing a >disconnect. Or is there something I missed in setting up the client >channel >table? I also noticed that the Server Qmanager does shutdown when I >physically terminate there MQ Client application. > >Also, thanks so much for the tips on the 2009 and 2016 Return Codes. I >will >definitely put that information to good use before signing off on this >vendors MQ Client developed application. > >Any other tips of things to watch out for from vendor developed MQ Clients >would be appreciated. > >Thanks so much, > >Joe > > > > _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.ak
Re: Vulnerabilities for Client Concentrator Model
The channel I was talking about was the one from my HUB QM to the Concentrator QM. If messages coming in from the HUB were landing on a local queue on the concentrator, and that queue filled up, and then the DLQ filled up, then the channel from the HUB to the Concentrator would go down. In this case, putting apps on remote queue managers would still be putting messages without any errors, yet none of their messages could make it to the concentrator, all because of AppA. Sorry I wasn't more clear originally. Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: Re: Vulnerabilities for Client Concentrator Model Peter, I am not sure if the CLient Channel will go down because a Queue is at the 'brim'. This would be the effect in a server channel. In a client channel the app would receive an error message back with a reurn code. Also, items normally/only go to the DLQ when there is no connected app to which MQ can return a RC. In your case the client would get the RC. In a server to server connection the app is long gone so the message goes to the DLQ. bobbee >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Vulnerabilities for Client Concentrator Model >Date: Wed, 20 Nov 2002 12:58:19 -0500 > >If you have 100 apps all client connected to a central MQ server, what are >the various ways that AppA can negatively effect AppB? > >For instance, AppA's input queue from the outside world fills up, because >app A is down. Now the MCA starts putting the messages to the DLQ, and it >fills up. Now the channel to the outside world goes down, and everyone is >effected. > >What else can happen? > > > > > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > > >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 _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: SECURITY ISSUES ON MQ QUEUE
Mohamed, Your racf definitions each have a blank after the MQD6. If this is indeed how the definitions are written, I suspect that is your problem. Instead of: PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) You should have PERMIT MQD6.SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS(UPDATE) Cheers, Doug Middleware Group MailboxTo: [EMAIL PROTECTED] Subject: SECURITY ISSUES ON MQ QUEUE 11/20/2002 01:22 PM Please respond to MQSeries List ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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: SECURITY ISSUES ON MQ QUEUE
Do you specify PUTAUT(CTX) on the CY3KC.TO.MQD6 receiver channel? Did you refresh the RACF profiles? What RACF errors are you getting? - Bruce Giordano Prudential Financial Middleware Group Mailbox <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Sent by: MQSeries List Subject: SECURITY ISSUES ON MQ QUEUE <[EMAIL PROTECTED]> Wednesday November 20, 2002 01:22 PM Please respond to MQSeries List ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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: SECURITY ISSUES ON MQ QUEUE
Take a look at syslog. The RACF violation message there should show the userid that is failing. Middleware Group Mailbox To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: M> Subject: SECURITY ISSUES ON MQ QUEUE Sent by: MQSeries List 11/20/2002 01:22 PM Please respond to MQSeries List ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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
SECURITY ISSUES ON MQ QUEUE
ello, I have MQ5.2 installed in my workstation and on the OS/390. In my worstation I use amqsput to put a message to the remote queue SECURITY.TEST.Q which is defined on queue manager MQD6 on OS/390 as SECURITY.TEST.Q (local queue). The RACF DEFINITIONS ARE: RDEFINE MQQUEUE MQD6. SECURITY.TEST.Q UACC (NONE) OW (SYS1) PERMIT MQD6. SECURITY.TEST.Q CLASS (MQQUEUE) ID (TS0001) ACCESS (UPDATE) RDEFINE MQQUEUE MQD6. * UACC (READ) OW (SYS1) PERMIT MQD6. * CLASS (MQQUEUE)ID (MQD6MSTR, MQD6CHIN, TS0001) ACCESS (ALTER) But I am getting these errors messages: +CSQX500I D6* CSQXRESP Channel CY3KC.TO.MQD6 started +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open MQD6.DEAD.QUEUE, MQCC=2 MQRC=2035 +CSQX036E D6* CSQXRESP Unable to open SECURITY.TEST.Q, MQCC=2 MQRC=2035 +CSQX545I D6* CSQXRESP Channel CY3KC.TO.MQD6 closing because disconnect interval +CSQX501I D6* CSQXRESP Channel CY3KC.TO.MQD6 is no longer active *** Bottom of Data Any comment is welcomed. Thanks, Mohamed. Instructions for managing your mailing list 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: Vulnerabilities for Client Concentrator Model
Peter, I am not sure if the CLient Channel will go down because a Queue is at the 'brim'. This would be the effect in a server channel. In a client channel the app would receive an error message back with a reurn code. Also, items normally/only go to the DLQ when there is no connected app to which MQ can return a RC. In your case the client would get the RC. In a server to server connection the app is long gone so the message goes to the DLQ. bobbee From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Vulnerabilities for Client Concentrator Model Date: Wed, 20 Nov 2002 12:58:19 -0500 If you have 100 apps all client connected to a central MQ server, what are the various ways that AppA can negatively effect AppB? For instance, AppA's input queue from the outside world fills up, because app A is down. Now the MCA starts putting the messages to the DLQ, and it fills up. Now the channel to the outside world goes down, and everyone is effected. What else can happen? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 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 _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries classes for Java and OpenVMS
Emile, I saw that. My only hope was the OpenVMS System Administration Guide Version 5.1 mentions that a new feature for this version is "MQSeries for Compaq OpenVMS now works with Java compilers". Does anyone know if there are plans to support the Java API on OpenVMS in the future, and if so, when? Thanks, Mike Emile Kearns <[EMAIL PROTECTED]> wrote: Hi Mike, Here is the website for the Java Classes and I see nothing for OpenVms: http://www14.software.ibm.com/webapp/download/search.jsp?go=y&rs=mqscl Emile Kearns Office telephone no: +27(0)114586670 SOFTWARE FUTURESthe business advantageProud member of MGXwww.softwarefutures.com -Original Message-From: Mike Spellman [mailto:[EMAIL PROTECTED]] Sent: 19 November 2002 09:44To: [EMAIL PROTECTED]Subject: MQSeries classes for Java and OpenVMS Anyone know if there are MQSeries classes for Java for OpenVMS? Thanks, Mike Do you Yahoo!?Yahoo! Web Hosting - Let the expert host your siteDo you Yahoo!? Yahoo! Web Hosting - Let the expert host your site
Re: Client/Server channel security
Alas, the UNIX security people got back to me and it seems that the user 'applic' was denied access to the server. They allowed it access and my connection works fine. The rub is that they don't want to allow access to the server for this user; and they are concerned that I will request too many security groups. For the moment I am looking to use server-conn MCA User security to protect the MQ objects. And then move toward user-exits for the next level of security later. How have you set up UNIX groups to use server-conn channels to protect MQ objects? _ Regards, Dick Killian MQ Administrator & Adabas DBA Rochester Gas & Electric Corp Jim Ford <[EMAIL PROTECTED]To: [EMAIL PROTECTED] M> cc: Sent by: MQSeriesSubject: Re: [MQSERIES] Client/Server channel security List 11/20/2002 11:46 AM Please respond to MQSeries List Are you getting the 2035 on the connect or on the open? Did you run setmqaut commands for the queue manager as well as the queue? What does 'dspmqaut -t qmgr -m -g appgrp' (or -p applic) do you see that connect authority? Richard Killian cc: Sent by: MQSeriesSubject: Client/Server channel security List 11/20/2002 10:27 AM Please respond to MQSeries List MQSeries 5.2, CSD 4 I am trying to implement security via the MCAUSER on the SVRCONN channel. The QMgr is on an AIX/Unix box and the client comes from both AIX/Unix and Windows/NT (the same application from both). There is a security group for the application 'appgrp'. I ran setmqaut commands to establish the required access for this group (i.e. +g appgrp). There are 3 users in the group 'appgrp': 1. applic this is a non login user defined for internal use in the application (i.e. it does not have a shell) 2. usr123 3. usrabc when I code 'appgrp' or 'applic' in the server-conn channel's MCA User field I get a 2035. when I code 'usr123' or 'usrabc' in the server-conn channel's MCA User field I can get access to the QMgr. At first I thought this might be related to 'applic' being a non-login account but then I realized that 'mqm' is also a non-logon account and 'mqm' works fine. Does anyone have any insight that are willing to share about this? _ Regards, Dick Killian Instructions for managing your mailing list 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
Vulnerabilities for Client Concentrator Model
If you have 100 apps all client connected to a central MQ server, what are the various ways that AppA can negatively effect AppB? For instance, AppA's input queue from the outside world fills up, because app A is down. Now the MCA starts putting the messages to the DLQ, and it fills up. Now the channel to the outside world goes down, and everyone is effected. What else can happen? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Problem with JMS Message selector.
Thanks James and Frank for your suggestions and analysis.I will use this information and let you know if we are able to overcome this. regds Gaurav -Original Message- From: James Kingdon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 7:22 AM To: MQSeries List Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Problem with JMS Message selector. Hi, Just a couple of things to add to Frank's response... It's not quite the expected behaviour, I would expect the non-matching messages to be removed from the subscription queues. Exactly when this happens depends on the type of Session used. For non-transacted sessions using auto or dups_ok acknowledgement the messages should be removed as soon as they have been run against the selector and found not to match. For transacted sessions they will remain until the application calls session.commit(), at which point all messages that have failed the selector(s) (on all Subscribers created from that session) will be simultaneously removed. Similarly, for non-transacted sessions using client acknowledge, the non-matching messages will be removed in batches whenever there is a call to Message.acknowledge for any messages consumed via the Subscribers of that session. If you are seeing message accumulation on your subscription queues (for which you have active subscribers), this would suggest that you are using either transacted or client_acknowledge mode with very few commits/acknowledge calls on each session. Is this a possibility? This might be the result of a programming error, but can sometimes happen with subscriptions that select for 'rare' messages on busy Topics. Regarding the difference between JMS selectors and MQSI content filters that Frank mentions, it's worth pointing out that the latest version of MQJMS (MQ5.3 CSD1) can make use of MQSI content filters for JMS selectors, allowing message selectors to be run either on the client side or the server side. This is also possible with MQSeries Event Broker, but not with the MA0C SupportPac. Event Broker additionally benefits from the direct connect option for high performance non-persistent messaging. Finally, I think the option that Frank mentions for dealing with unwanted messages is specific to Connection Consumers (the ASF part of the JMS specification). Whilst it's possible that the original post was relating to Connection Consumers, it's relatively unlikely. For 'normal' subscribers you shouldn't need to change any properties to remove unwanted messages. Cheers, James. Christopher Frank wrote: >Gaurav, > > > We are having issues with JMS message selectors with MQSI 2.1. The scenario is we have two durable subscriber on the same topic but with different message selectors and pointing to different subscription queues.Our understanding from the documents was that only messages which meet the message selector condition will be delivered by mqsi to the subscriber queues.But what is happening is that all messages reach both the subscriber queues.Now when the subscribing application runs it picks the messgaes meant for it but the remaining messages remain there in the queue.This keeps filling our queues with a potential of overflowing. Has anyone used message selectors? Is this the expected behaviour or are we doing something wrong. > >This is the expected behavior when using JMS selectors. The behavior you >say you understand from the documents (MQSI, I presume) is the behavior for >content filters, but JMS uses a different approach with selectors, because >JMS selectors must work in both the pub/sub and point-to-point domains. > >MQSeries supports the JMS capability to permit multiple consumers, each >with different selectors, to share the same underlying queue. This can >result in unwanted messages if there is no consumer with a matching >selector, which appears to be what you are seeing. You must specify what >action you want JMS to take in the event of unwanted messages. How to do >this is described in the JMS section of the "Using Java" manual. > >Regards, > >Christopher Frank >Sr. I/T Specialist - IBM Software Group >IBM Certified Solutions Expert - Websphere MQ & MQ Integrator > >Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 >e-mail: [EMAIL PROTECTED] > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > Instructions for managing your mailing list 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: MQMQ MsgID - valid characters
Title: MQMQ MsgID - valid characters Ben, You may have a problem. The MsgId field is in the following format: 1-4 is a constant; either 'CSQ ' or 'AMQ ' 5-16 is the first 12 characters of the queue manager name 17-24 is a time stamp (a binary number), TOD clock on z/900, system clock from other servers It could be possible to hit a binary number sequence which may give you trouble. The only thing you may be able to do is convert the 8 byte binary number to 16 bytes of character data, pass it along and then reconvert back to binary at the other end. Pope, Ben wrote: I have a situation where I need to pass the MsgId contents as part of an XML message. What I've found in the docs describes how the field in constructed by the queue manger but it is described as being simply "a byte field". Are there any details as to what byte range could be used? Specifically, codes between 0x00 and 0x20 are considered invalid XML and if they can be included in the MsgId field then I need to account for that possibility. Thanks, Ben -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000
Re: MQMQ MsgID - valid characters
Ben, I believe you must be able to account for all possible byte values between 0x00 and 0xFF unless you generate the message IDs yourself. Even if the MQ generated IDs don't use all possible byte values now, they very well may in the future. Regards, Chris "Pope, Ben" cc: Sent by: Subject: MQMQ MsgID - valid characters MQSeries List 11/20/02 10:35 AM Please respond to MQSeries List I have a situation where I need to pass the MsgId contents as part of an XML message. What I've found in the docs describes how the field in constructed by the queue manger but it is described as being simply "a byte field". Are there any details as to what byte range could be used? Specifically, codes between 0x00 and 0x20 are considered invalid XML and if they can be included in the MsgId field then I need to account for that possibility. 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: MQMQ MsgID - valid characters
If you are using the Windows COM object model, you can get or put the MsgId as Hex characters (E2A1B3F4, etc.) ; then you can use this as a 'string' and save that in the XML. From: "Pope, Ben" <[EMAIL PROTECTED]> on 11/20/2002 11:35 AM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: MQMQ MsgID - valid characters I have a situation where I need to pass the MsgId contents as part of an XML message. What I've found in the docs describes how the field in constructed by the queue manger but it is described as being simply "a byte field". Are there any details as to what byte range could be used? Specifically, codes between 0x00 and 0x20 are considered invalid XML and if they can be included in the MsgId field then I need to account for that possibility. 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
Licensing question on use of MQIPT.
Hi Urvesh, Yes, current users of MQSeries can download MQIPT and use it for free and you can contact IBM for defect correction before you use it in production, until the specified End of Service date. >Hi, >Pasted below is the section from IBM's supportPacs link for MQSeries: >http://www-3.ibm.com/software/ts/mqseries/txppacs/txpm2.html#cat3 >== >Product Extensions (Category 3) SupportPacs >SupportPacs in this category are available at no charge to all users of >MQSeries products. They are supplied under the standard terms and conditions >contained in the IBM International Program License Agreement (IPLA) and >provide for defect correction until a defined End of Service date. >== > >Although it says that all the supportPacs under this category are free to >all users, I wanted to confirm that any current user of MQSeries can indeed >use MS81 (MQ Interner pass-thru) supportPac (which falls under this category >of supportPacs) in their production environment free of any charge, and if >IBM needs to be contacted before it's use in production. > >Thanks in advance for your help. > >Best regards, > >Urvesh. Phil Blake Instructions for managing your mailing list 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: MQMQ MsgID - valid characters
Title: MQMQ MsgID - valid characters Ben, The MsgId can indeed contain characters that are invalid XML. Typically when we have had a need to pass around a MsgId in XML, we will encode the entrire MsgId as base 16 or base 64. Hope this helps, Bill Reiss Developer CommerceQuest, Inc. Enabling the Dynamic Enterprise www.commercequest.com -Original Message-From: Pope, Ben [mailto:[EMAIL PROTECTED]]Sent: Wednesday, November 20, 2002 11:36 AMTo: [EMAIL PROTECTED]Subject: MQMQ MsgID - valid characters I have a situation where I need to pass the MsgId contents as part of an XML message. What I've found in the docs describes how the field in constructed by the queue manger but it is described as being simply "a byte field". Are there any details as to what byte range could be used? Specifically, codes between 0x00 and 0x20 are considered invalid XML and if they can be included in the MsgId field then I need to account for that possibility. Thanks, Ben
Re: Client/Server channel security
Are you getting the 2035 on the connect or on the open? Did you run setmqaut commands for the queue manager as well as the queue? What does 'dspmqaut -t qmgr -m -g appgrp' (or -p applic) do you see that connect authority? Richard Killian cc: Sent by: MQSeriesSubject: Client/Server channel security List 11/20/2002 10:27 AM Please respond to MQSeries List MQSeries 5.2, CSD 4 I am trying to implement security via the MCAUSER on the SVRCONN channel. The QMgr is on an AIX/Unix box and the client comes from both AIX/Unix and Windows/NT (the same application from both). There is a security group for the application 'appgrp'. I ran setmqaut commands to establish the required access for this group (i.e. +g appgrp). There are 3 users in the group 'appgrp': 1. applic this is a non login user defined for internal use in the application (i.e. it does not have a shell) 2. usr123 3. usrabc when I code 'appgrp' or 'applic' in the server-conn channel's MCA User field I get a 2035. when I code 'usr123' or 'usrabc' in the server-conn channel's MCA User field I can get access to the QMgr. At first I thought this might be related to 'applic' being a non-login account but then I realized that 'mqm' is also a non-logon account and 'mqm' works fine. Does anyone have any insight that are willing to share about this? _ Regards, Dick Killian Instructions for managing your mailing list 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
MQMQ MsgID - valid characters
Title: MQMQ MsgID - valid characters I have a situation where I need to pass the MsgId contents as part of an XML message. What I've found in the docs describes how the field in constructed by the queue manger but it is described as being simply "a byte field". Are there any details as to what byte range could be used? Specifically, codes between 0x00 and 0x20 are considered invalid XML and if they can be included in the MsgId field then I need to account for that possibility. Thanks, Ben
Client/Server channel security
MQSeries 5.2, CSD 4 I am trying to implement security via the MCAUSER on the SVRCONN channel. The QMgr is on an AIX/Unix box and the client comes from both AIX/Unix and Windows/NT (the same application from both). There is a security group for the application 'appgrp'. I ran setmqaut commands to establish the required access for this group (i.e. +g appgrp). There are 3 users in the group 'appgrp': 1. applic this is a non login user defined for internal use in the application (i.e. it does not have a shell) 2. usr123 3. usrabc when I code 'appgrp' or 'applic' in the server-conn channel's MCA User field I get a 2035. when I code 'usr123' or 'usrabc' in the server-conn channel's MCA User field I can get access to the QMgr. At first I thought this might be related to 'applic' being a non-login account but then I realized that 'mqm' is also a non-logon account and 'mqm' works fine. Does anyone have any insight that are willing to share about this? _ Regards, Dick Killian Instructions for managing your mailing list 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: Convert a message to a single readable "string" in WMQI
Try with this: OutputRoot.XML.WmqiDiagnostic.OriginalMessage = BITSTREAM(InputBody); You migth need use the Encoding and CodedCharSetId. I recommend you to use those field from your input message. Cheers, Manuel Carlos Rodriguez IBM Certified Specialist - MQSeries > -Mensaje original- > De: John Scott [SMTP:[EMAIL PROTECTED]] > Enviado el: Wednesday, November 20, 2002 4:33 PM > Para: [EMAIL PROTECTED] > Asunto: Convert a message to a single readable "string" in WMQI > > In WMQI if I want to create a diagnostic message in a compute node such > as: > > OutputRoot.XML.WmqiDiagnostic.OriginalExceptionList = InputExceptionList > OutputRoot.XML.WmqiDiagnostic.OriginalMessage = InputRoot.< here>> > > How can I cast the whole message body as a single string? > > If I reset the content descriptor to a BLOB, and use plain "InputRoot", > then I get the original message as hex which is not readable. I want the > original message, but in a more readable format (marked up with & > etc.) > > Is there any way of reliably doing this, without knowing what the input > message is going to look like (they might send me garbage). I don't want > my diagnostic recording sub-flow from blowing up because of a garbaged > message (e.g. invalid XML such as ""). I would be happy for > this to be marked up in XML to "<..." as this would > display OK in something like an Internet Explorer... > > Regards > John. > > > > > ** > > Click here to visit the Argos home page http://www.argos.co.uk > > The information contained in this message or any of its attachments may be > privileged and confidential, and is intended exclusively for the > addressee. > The views expressed may not be official policy, but the personal views of > the originator. > If you are not the intended addressee, any disclosure, reproduction, > distribution, dissemination or use of this communication is not > authorised. > If you have received this message in error, please advise the sender by > using your reply facility in youe e-mail software. > All messages sent and received by Argos Ltd are monitored for virus, high > risk file extensions, and inappropriate content. As a result users should > be aware that mail maybe accessed. > > ** > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Peter Henningsen/Australia/IBM is out of the office.
I will be out of the office starting November 21, 2002 and will not return until November 25, 2002. I have a couple of day's leave - try mobile 0412.729.961 if urgent ... Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Convert a message to a single readable "string" in WMQI
Title: Convert a message to a single readable "string" in WMQI In WMQI if I want to create a diagnostic message in a compute node such as: OutputRoot.XML.WmqiDiagnostic.OriginalExceptionList = InputExceptionList OutputRoot.XML.WmqiDiagnostic.OriginalMessage = InputRoot.<> How can I cast the whole message body as a single string? If I reset the content descriptor to a BLOB, and use plain "InputRoot", then I get the original message as hex which is not readable. I want the original message, but in a more readable format (marked up with & etc.) Is there any way of reliably doing this, without knowing what the input message is going to look like (they might send me garbage). I don't want my diagnostic recording sub-flow from blowing up because of a garbaged message (e.g. invalid XML such as ""). I would be happy for this to be marked up in XML to "<..." as this would display OK in something like an Internet Explorer... Regards John. ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in youe e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. **
WMQIB 2.1 core dump during install
Any ideas why we get a core dump on AIX during WMQIB 2.1 install. Happens when busy with 9th MQAUTH command. No errors anywhere. Thanks. Francois van der Merwe Instructions for managing your mailing list 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: Problem with JMS Message selector.
Hi, Just a couple of things to add to Frank's response... It's not quite the expected behaviour, I would expect the non-matching messages to be removed from the subscription queues. Exactly when this happens depends on the type of Session used. For non-transacted sessions using auto or dups_ok acknowledgement the messages should be removed as soon as they have been run against the selector and found not to match. For transacted sessions they will remain until the application calls session.commit(), at which point all messages that have failed the selector(s) (on all Subscribers created from that session) will be simultaneously removed. Similarly, for non-transacted sessions using client acknowledge, the non-matching messages will be removed in batches whenever there is a call to Message.acknowledge for any messages consumed via the Subscribers of that session. If you are seeing message accumulation on your subscription queues (for which you have active subscribers), this would suggest that you are using either transacted or client_acknowledge mode with very few commits/acknowledge calls on each session. Is this a possibility? This might be the result of a programming error, but can sometimes happen with subscriptions that select for 'rare' messages on busy Topics. Regarding the difference between JMS selectors and MQSI content filters that Frank mentions, it's worth pointing out that the latest version of MQJMS (MQ5.3 CSD1) can make use of MQSI content filters for JMS selectors, allowing message selectors to be run either on the client side or the server side. This is also possible with MQSeries Event Broker, but not with the MA0C SupportPac. Event Broker additionally benefits from the direct connect option for high performance non-persistent messaging. Finally, I think the option that Frank mentions for dealing with unwanted messages is specific to Connection Consumers (the ASF part of the JMS specification). Whilst it's possible that the original post was relating to Connection Consumers, it's relatively unlikely. For 'normal' subscribers you shouldn't need to change any properties to remove unwanted messages. Cheers, James. Christopher Frank wrote: Gaurav, We are having issues with JMS message selectors with MQSI 2.1. The scenario is we have two durable subscriber on the same topic but with different message selectors and pointing to different subscription queues.Our understanding from the documents was that only messages which meet the message selector condition will be delivered by mqsi to the subscriber queues.But what is happening is that all messages reach both the subscriber queues.Now when the subscribing application runs it picks the messgaes meant for it but the remaining messages remain there in the queue.This keeps filling our queues with a potential of overflowing. Has anyone used message selectors? Is this the expected behaviour or are we doing something wrong. This is the expected behavior when using JMS selectors. The behavior you say you understand from the documents (MQSI, I presume) is the behavior for content filters, but JMS uses a different approach with selectors, because JMS selectors must work in both the pub/sub and point-to-point domains. MQSeries supports the JMS capability to permit multiple consumers, each with different selectors, to share the same underlying queue. This can result in unwanted messages if there is no consumer with a matching selector, which appears to be what you are seeing. You must specify what action you want JMS to take in the event of unwanted messages. How to do this is described in the JMS section of the "Using Java" manual. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list 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: supportPac IC01 question
Title: Message This will happen if the "mqsiexportmsgflows" command is actually a batch/command file (.bat/.cmd extension). When writing your own batch file, you must "call" other batch files, otherwise control is transferred to the sub-batch file which never "returns". John. -Original Message-From: Benjamin Zhou [mailto:[EMAIL PROTECTED]] Sent: 20 November 2002 13:25To: [EMAIL PROTECTED]Subject: Re: supportPac IC01 question Hi Yasuo, great, it did the trick. I was never aware of this "call" command. Many thanks, Ben -Original Message- From: Yasuo Takei [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:46 AM To: [EMAIL PROTECTED] Subject: Re: supportPac IC01 question How about adding "call" to the beginning of each line? Yasuo Takei Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: supportPac IC01 question N.AC.AT> 2002/11/20 03:56 Please respond to MQSeries List Hi, I'm trying to use the mqsiexportmsgflows in IC01 to automate export activity by generating a batch script containing the following: (on Win2k) mqsiexportmsgflows MSGFLOW1.xml -m MSGFLOW1 mqsiexportmsgflows MSGFLOW2.xml -m MSGFLOW2 mqsiexportmsgflows MSGFLOW3.xml -m MSGFLOW3 mqsiexportmsgflows MSGFLOW4.xml -m MSGFLOW4 mqsiexportmsgflows MSGFLOW5.xml -m MSGFLOW5 hoping they will be executed in a sequence. But instead, it export only the first one and stops at command line. I eventually added "start" to the beginning, and "/b" to the end of each line. which then created as many batch jobs as the number of lines, which I had to close one by one afterwards. Does anyone know how to run it in one shot? thanks a lot. Benjamin Zhou Princeton Financial Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in youe e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. **
Re: supportPac IC01 question
Title: RE: supportPac IC01 question Hi Yasuo, great, it did the trick. I was never aware of this "call" command. Many thanks, Ben -Original Message- From: Yasuo Takei [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 5:46 AM To: [EMAIL PROTECTED] Subject: Re: supportPac IC01 question How about adding "call" to the beginning of each line? Yasuo Takei Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeries cc: List Subject: supportPac IC01 question N.AC.AT> 2002/11/20 03:56 Please respond to MQSeries List Hi, I'm trying to use the mqsiexportmsgflows in IC01 to automate export activity by generating a batch script containing the following: (on Win2k) mqsiexportmsgflows MSGFLOW1.xml -m MSGFLOW1 mqsiexportmsgflows MSGFLOW2.xml -m MSGFLOW2 mqsiexportmsgflows MSGFLOW3.xml -m MSGFLOW3 mqsiexportmsgflows MSGFLOW4.xml -m MSGFLOW4 mqsiexportmsgflows MSGFLOW5.xml -m MSGFLOW5 hoping they will be executed in a sequence. But instead, it export only the first one and stops at command line. I eventually added "start" to the beginning, and "/b" to the end of each line. which then created as many batch jobs as the number of lines, which I had to close one by one afterwards. Does anyone know how to run it in one shot? thanks a lot. Benjamin Zhou Princeton Financial Instructions for managing your mailing list 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: MO12 - MQSeries for OS/390 - Log extract program Version 2.2
All I got this working so I thought I would share my results. This support PAC (V2.2) no longer requires a REXX compiler :-). There is a USERMOD on the CSQ1LOGP program (i.e. log print utility) that allows the dump of an archive log so the MO12 C program can replay messages back into a queue. My updated version of the C code seemed to have no problems with processing the output of the enhanced CSQ1LOGP utility. I forwarded this C code to the author for his review. This support PAC works in V5.2 currently. The author is trying to find time for supporting V5.3 since it is a category 2 support PAC. This is a great product. I would recommend making this part of the base WebSphere MQ code or at least a category 3 product extension. Thanks Frank -Original Message- From: Bright, Frank [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 8:59 AM To: [EMAIL PROTECTED] Subject: MO12 - MQSeries for OS/390 - Log extract program Version 1.0 I recently downloaded this support PAC but had problems compiling the C program source that is used to replay messages ( among other things). I finally got it to compile but I had to move some instructions around and make other minor changes within the source. There were some instructions that set variables to values above statements that defined variables. Did anyone else encounter the same or similar C compile problems I am describing? I looked at the Vienna search site (http://messageq.ebizq.net/vienna/msg_head.php3) and saw an old thread on MO12 that discussed the REXX compiler problems related to executing the supplied REXX executable. I did not see any follow ups on how that turned out. My understanding is that the REXX executable did not execute. I am hopeful someone got past that error and could fill me in on what was done. We are still in the process of getting the REXX compiler delivered and installed. Thanks Frank Instructions for managing your mailing list 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: NT trigger monitor
Zuo, Have a look at the following supportpac http://www-3.ibm.com/software/ts/mqseries/txppacs/ma7k.html Matt Gurney ZUO Limin <[EMAIL PROTECTED]> UOBGROUP.COM Sent by: MQSeries List <[EMAIL PROTECTED]> 20/11/2002 09:25 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: NT trigger monitor Hi, Does anybody have the experience to set up the NT trigger monitor as NT service? Thanks in advance, Limin Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
WMQI 2.1 and New Era of Networks product code
I have installed WebSphere MQ Integrator at a client site, with the broker running on Solaris. Message flows work fine, as long as they do not include any NEON nodes. The "WebSphere MQ Integrator Deployment and Migration" redbook states that "You need to install the New Era Of Networks code before installing the WebSphere MQ Integrator product itself. Otherwise, you cannot select the New Era Of Networks integration package that is part of the WebSphere MQ Integrator product." Having issued pkgadd from the NNSY/nnsy directory first, the options available on the pkgadd from the wmqi directory include the "WMQI NNSY Interface". Is this the same as the New Era of Networks integration package or is there soemthing else that needs to be done to make this option available? The software version is WMQI 2.1. CSD 3 was applied to NNSY and WMQI after this step. The message flows can be deployed with a Neon node. However, a core dump is produced whenever a message is passed through the flow (with very little extra information). Has anybody experienced this? Thanks, Tim Crossland _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: supportPac IC01 question
How about adding "call" to the beginning of each line? Yasuo Takei Benjamin Zhou <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: supportPac IC01 question 2002/11/20 03:56 Please respond to MQSeries List Hi, I'm trying to use the mqsiexportmsgflows in IC01 to automate export activity by generating a batch script containing the following: (on Win2k) mqsiexportmsgflows MSGFLOW1.xml -m MSGFLOW1 mqsiexportmsgflows MSGFLOW2.xml -m MSGFLOW2 mqsiexportmsgflows MSGFLOW3.xml -m MSGFLOW3 mqsiexportmsgflows MSGFLOW4.xml -m MSGFLOW4 mqsiexportmsgflows MSGFLOW5.xml -m MSGFLOW5 hoping they will be executed in a sequence. But instead, it export only the first one and stops at command line. I eventually added "start" to the beginning, and "/b" to the end of each line. which then created as many batch jobs as the number of lines, which I had to close one by one afterwards. Does anyone know how to run it in one shot? thanks a lot. Benjamin Zhou Princeton Financial Instructions for managing your mailing list 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: NT trigger monitor
Go to the WebSphere Services Panel, Right Click on the Queue Manager, Choose New and Trigger Monitor, On the Parameters Tab, enter the Initiation Queue name (must be defined), Look to see if you are happy with the parameters in the General and Recovery Tabs and press enter. That is the Trigger monitor service set up. Emile Kearns Office telephone no: +27(0)114586670 SOFTWARE FUTURES the business advantage Proud member of MGX www.softwarefutures.com -Original Message- From: ZUO Limin [mailto:[EMAIL PROTECTED]] Sent: 20 November 2002 11:26 To: [EMAIL PROTECTED] Subject: NT trigger monitor Hi, Does anybody have the experience to set up the NT trigger monitor as NT service? Thanks in advance, Limin Instructions for managing your mailing list 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
NT trigger monitor
Hi, Does anybody have the experience to set up the NT trigger monitor as NT service? Thanks in advance, Limin Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Last access on the local queue
Hi, How can I confirm when was the last time the queue is being used by the application? Any specific commands to check on this status or log store the information. Thanks. __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Trigger problem
Hi all, Chapter 14 of the Applications Programming Guide has a good topic: What is triggering? -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: 19 November 2002 09:52 To: [EMAIL PROTECTED] Subject: Re: Trigger problem My initiation queue definition points to a process name. Should I leave this blank? I thought I had to point to a process name and therefore have two process names and two trigger monitors. The process name is on the Trigger panel of the process definition. -Original Message- From: Stefan Sievert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 12:42 PM To: [EMAIL PROTECTED] Subject: Re: Trigger problem The obvious question would be: why? ;-) You really only need one INITQ in most cases, unless - as Dennis pointed out - you have different trigger monitors; or a very high triggering volume and you want to workload-balance trigger message processing. I haven't come across an installation where two trigmons were needed (or used) for a given queue manager (whatever that means). but, if you do have two INITQ's, you might need two trigger monitors. I would save myself the hassle and additional overhead and just use one. If you odon't want to change all your triggered queue definitions you might already have, you can always create an alias for the 'second' INITQ pointing to the 'first' and do the cleanup one-by-one. HTH, Stefan >From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Trigger problem >Date: Tue, 19 Nov 2002 09:19:55 -0600 > >But we are also using a different init queue. > >-Original Message- >From: Stefan Sievert [mailto:[EMAIL PROTECTED]] >Sent: Monday, November 18, 2002 4:20 PM >To: [EMAIL PROTECTED] >Subject: Re: Trigger problem > > >Doesn't matter, it's the process definition which controls what gets >triggered. One trigger monitor is all you need. >Stefan > > > >From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: Trigger problem > >Date: Mon, 18 Nov 2002 14:57:30 -0600 > > > >It triggers a different program in a different directory. > > > >-Original Message- > >From: Miller, Dennis [mailto:[EMAIL PROTECTED]] > >Sent: Monday, November 18, 2002 11:19 AM > >To: [EMAIL PROTECTED] > >Subject: Re: Trigger problem > > > > > >Unless you have extenuating circumstances, one trigger monitor should >work > >for both applications. > > > > > > > -Original Message- > > > From: Anderson, Lizette T. (RyTull) > > > [SMTP:[EMAIL PROTECTED]] > > > Sent: Friday, November 15, 2002 8:13 AM > > > To: [EMAIL PROTECTED] > > > Subject: Trigger problem > > > > > > I am having problems triggering a program on a Windows 2000 server. >The > > > triggering works fine with the runmqtrm command from the command line, > >but > > > when I set the trigger monitor up using MQservices, it does not >trigger. > > > I > > > already have one(successfully running trigger monitor) setup under > > > services, > > > so the new monitor is showing up as TRIGGER MONITOR(2). Any ideas? >We > > > only > > > have two programs that need to be triggered on the server. We are > >running > > > MQ 5.2. > > > > > > > > > --- Legal Disclaimer: The information contained in this communication > >may > > > be > > > confidential, is intended only for the use of the recipient named >above, > > > and > > > may be legally privileged. If the reader of this message is not the > > > intended recipient, you are hereby notified that any dissemination, > > > distribution, or copying of this communication, or any of its >contents, > >is > > > strictly prohibited. If you have received this communication in >error, > > > please re-send this communication to the sender and delete the >original > > > message and any copy of it from your computer system. Thank you. --- > > > > > > Instructions for managing your mailing list subscription are provided >in > > > the Listserv General Users Guide available at http://www.lsoft.com > > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > >Instructions for managing your mailing list subscription are provided in > >the Listserv General Users Guide available at http://www.lsoft.com > >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > > >--- Legal Disclaimer: The information contained in this communication may > >be > >confidential, is intended only for the use of the recipient named above, > >and > >may be legally privileged. If the reader of this message is not the > >intended recipient, you are hereby notified that any dissemination, > >distribution, or copying of this communication, or any of its contents, >is > >strictly prohibited. If you have received this communication in error, > >please re-send this communication to the sender and delete the original > >message and any copy of it from your computer system.
