Question regarding MQRC_OBJECT_IN_USE
Hello, I try to troubleshoot a problem where I open a queue with MQOO_INPUT_SHARED and MQOPEN fails and returns reason code MQRC_OBJECT_IN_USE . Configuration: both client and server Win2000, MQSeries 5.2 I run my code on MQSeries client, against the remote MQSeries server. First call is ok. Then my process crash, I run it again and now MQOPEN fail. Any ideas what can be the problem ? or how to troubleshoot it ? Thanks, Doron _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Cade Hewitt/Treasury/Aust_Bank/National Australia Bank/AU is out of the office.
I will be out of the office starting 11/02/2004 and will not return until 19/02/2004. I will respond to your message when I return. Any MQSeries related notes can be forwarded to Jacque Lawrence. Thank you, Cade Hewitt __ The information contained in this email communication may be confidential. You should only disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Any views expressed in this email communication are those of the individual sender, except where the sender specifically states them to be the views of a member of the National Australia Bank Group of companies. Any advice contained in this e-mail has been prepared without taking into account your objectives, financial situation or needs. Before acting on any advice in this e-mail, National Australia Bank Limited recommends that you consider whether it is appropriate for your circumstances. If this e-mail contains reference to any financial products, the National recommends you consider the Product Disclosure Statement (PDS) or other disclosure document before making any decisions regarding any products. The National Australia Bank Group of companies does not represent, warrant or guarantee that the integrity of this communication has been maintained nor that the communication is free of errors, virus or interference. Instructions for managing your mailing list 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: QRE: VPN's and MQ
I am accessing MQ servers over a VPN with no problems... > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Nick Dilauro > Sent: Tuesday, February 10, 2004 2:31 PM > To: [EMAIL PROTECTED] > Subject: QRE: VPN's and MQ > > Bill, > > I don't have an answer to the second question since I haven't > worked with clients and VPNs but I imagine it's similar. We > have VPNs set up for sender/receiver channels. As I > understand it the VPN has all the security so I don't think > you need SSL. You'd be doing redundant protection. The VPN > works at the network level so it's transparent to MQ. No > changes to the MQ confif should be needed. > > Nick > > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Anderson > Sent: Tuesday, February 10, 2004 1:25 PM > To: [EMAIL PROTECTED] > Subject: VPN's and MQ > > Has anyone set up access to MQ through a VPN connection? I > know it can be done, but I am not very heavy on how VPN's > work. One big question is: > > Would it be best to find a SSL capable VPN, or just any old > VPN and make use of SSL with in WMQ5.3? > > Another thing is, I'm sure VPN clients are available for > free, but what is the cost associated with the server side? > > Thanks > > Bill Anderson > WebSphere MQ Services > SITA Atlanta, GA > 770-303-3503 (office) > 404-915-3190 (cell) > [EMAIL PROTECTED] > http://www.mconnect.aero/ > > Instructions for managing your mailing list 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: VPN's and MQ
VPNs are set up at the transport level and they should be absolutely transparent to the applications that are using them including MQSeries. I participated in the project with several hundred queue managers deployed in hub and spoke across the U.S., all via a vpn or dedicated circuit to the hub. 99.99% VPN's already provide such services as encryption, signing and authenticity verification, see IPSEC standard for more information. You will have to analyze your security risks carefully to determine if you really want to use MQSeries SSL channel via a networking infrastructure that already provides the services that are included in the SSL. Probably not. Let us know. Mikhail. - Original Message - From: "Bill Anderson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 10, 2004 4:25 PM Subject: VPN's and MQ | Has anyone set up access to MQ through a VPN connection? I know it can be | done, but I am not very heavy on how VPN's work. One big question is: | | Would it be best to find a SSL capable VPN, or just any old VPN and make | use of SSL with in WMQ5.3? | | Another thing is, I'm sure VPN clients are available for free, but what is | the cost associated with the server side? | | Thanks | | Bill Anderson | WebSphere MQ Services | SITA Atlanta, GA | 770-303-3503 (office) | 404-915-3190 (cell) | [EMAIL PROTECTED] | http://www.mconnect.aero/ | | Instructions for managing your mailing list 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
QRE: VPN's and MQ
Bill, I don't have an answer to the second question since I haven't worked with clients and VPNs but I imagine it's similar. We have VPNs set up for sender/receiver channels. As I understand it the VPN has all the security so I don't think you need SSL. You'd be doing redundant protection. The VPN works at the network level so it's transparent to MQ. No changes to the MQ confif should be needed. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Anderson Sent: Tuesday, February 10, 2004 1:25 PM To: [EMAIL PROTECTED] Subject: VPN's and MQ Has anyone set up access to MQ through a VPN connection? I know it can be done, but I am not very heavy on how VPN's work. One big question is: Would it be best to find a SSL capable VPN, or just any old VPN and make use of SSL with in WMQ5.3? Another thing is, I'm sure VPN clients are available for free, but what is the cost associated with the server side? Thanks Bill Anderson WebSphere MQ Services SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list 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
VPN's and MQ
Has anyone set up access to MQ through a VPN connection? I know it can be done, but I am not very heavy on how VPN's work. One big question is: Would it be best to find a SSL capable VPN, or just any old VPN and make use of SSL with in WMQ5.3? Another thing is, I'm sure VPN clients are available for free, but what is the cost associated with the server side? Thanks Bill Anderson WebSphere MQ Services SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list 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: Cluster workload exit rejecting messages...
Hi Antony,
The flags specifying USER and AUTO is a normal situation for CLUSSDR
channels pointing to a repository.
The USER flag indicates that there is a static CLUSSDR channel defined to
that queue manager (that is, that queue manager is the 'primary' repository
for this queue manager). The AUTO flag says that a CLUSSDR (with the same
name) has been created based on the published information about how to
contact that queue manager.
When you join a queue manager into a cluster, you create CLUSRCVR and then
CLUSSDR channels. The CLUSSDR channel is used to connect to the full
repository, which then sends information back via the CLUSRCVR about all
repositories and some other stuff. The repository informatoin includes the
channel names, and includes information about the same named channel as has
already been used. Until you issue a REFRESH CLUSTER REPOS(YES) your queue
manager will use the AUTO defined channel, not the USER defined one. This
is important so that everyone uses a common definition of the channels to
send to each queue manager, rather than having the possibility of different
queue managers defining the CLUSSDR channels differently.
As to the value of the MQQMF_AVAILABLE flag, I believe that it indicates
not that the queue manager is running, but that it has not been suspended
(ie SUSPEND QMGR CLUSTER(...) has not been issued, or else RESUME QMGR
CLUSTER(...) has been issued on that queue manager). I would issue a DIS
CLUSQMGR(...) SUSPEND for the target queue manager and check the repository
state information. You should do this command at both queue managers in
case the state does not match, and issue a REFRESH CLUSTER (at both) if you
find a mismatch.
If the queue manager is not running, then the channel to it will end up in
RETRYING state. My Cluster Worklload exit excludes RETRYING channels for
this reason.
By the way, you may also want to consider having the exit perform some work
on an OPEN call. If you have any queues which are defined with
DEFBIND(OPEN) or an application which specifies BIND(OPEN) then the exit
will be called at OPEN time, rather than for each PUT.
Regards,
Neil C.
|-+>
| | Antony Boggis|
| | <[EMAIL PROTECTED]> |
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | n.AC.AT> |
| ||
| ||
| | 11/02/2004 07:00 |
| | Please respond to|
| | MQSeries List|
| ||
|-+>
>--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Cluster workload exit rejecting messages...
|
>--|
More information... We've added some logging to our exit and are seeing
some interesting results:
MQWXP * parms
This is passed to the exit by MQ.
If parms->ExitReason == MQXR_INIT, we return parms->ExitResponse2 =
MQXR2_DYNAMIC_CACHE to indicate that we supprt dynamic caching.
If parms->ExitReason != MQXR_CLWL_PUT, we return, having previously set
parms->ExitResponse = MQXCC_OK, since we only care about controlling
MQPUT's.
So, the very next things we do is check the target queue manager's
availability:
qmgr = parms->DestinationArrayPtr[ 0 ]
if ((qmgr->QMgrFlags & MQQMF_AVAILABLE) == 0)
{
parms->ExitResponse = MQXCC_SUPPRESS_FUNCTION;
return;
}
This is causing the exit to exit (!). However, I *KNOW* the remote queue
manager is available because I am connected to it, locally using runmqsc
and via Websphere MQ Explorer. The value in qmgr->QMgrFlags is 0x225B,
which (if my math is correct) equates to: (MQQMF_REPOSITORY_Q_MGR &
MQQMF_CLUSSDR_USER_DEFINED & MQQMF_CLUSSDR_AUTO_DEFINED), plus a bunch of
other flags (which the docs say are used internally). What I don't
understand is how both USER... & AUTO... are set.
tonyB.
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of
Antony Boggis
Sent: Tuesday, February 10, 2004 10:00 AM
To: [EMAIL PROTECTED]
Subject: Cluster workload exit reject messages...
I have a Solaris based environment (5.8, all running WMQ 5.3 CSD05)
with 6 queue managers in
Re: Cluster workload exit rejecting messages...
Title: RE: Cluster workload exit rejecting messages...
More information... We've added some logging to our exit and are seeing some interesting results:
MQWXP * parms
This is passed to the exit by MQ.
If parms->ExitReason == MQXR_INIT, we return parms->ExitResponse2 = MQXR2_DYNAMIC_CACHE to indicate that we supprt dynamic caching.
If parms->ExitReason != MQXR_CLWL_PUT, we return, having previously set parms->ExitResponse = MQXCC_OK, since we only care about controlling MQPUT's.
So, the very next things we do is check the target queue manager's availability:
qmgr = parms->DestinationArrayPtr[ 0 ]
if ((qmgr->QMgrFlags & MQQMF_AVAILABLE) == 0)
{
parms->ExitResponse = MQXCC_SUPPRESS_FUNCTION;
return;
}
This is causing the exit to exit (!). However, I *KNOW* the remote queue manager is available because I am connected to it, locally using runmqsc and via Websphere MQ Explorer. The value in qmgr->QMgrFlags is 0x225B, which (if my math is correct) equates to: (MQQMF_REPOSITORY_Q_MGR & MQQMF_CLUSSDR_USER_DEFINED & MQQMF_CLUSSDR_AUTO_DEFINED), plus a bunch of other flags (which the docs say are used internally). What I don't understand is how both USER... & AUTO... are set.
tonyB.
From: MQSeries List [mailto:[EMAIL PROTECTED]] On Behalf Of Antony Boggis
Sent: Tuesday, February 10, 2004 10:00 AM
To: [EMAIL PROTECTED]
Subject: Cluster workload exit reject messages...
I have a Solaris based environment (5.8, all running WMQ 5.3 CSD05) with 6 queue managers involved across four hosts.
All the queue managers are running.
The issue I am having is that periodically the cluster workload exit is rejecting messages that are put to a remote cluster queue when it thinks that the channel to the remote manager is not up (state != Running). However, there is no corresponding channel event logged (on either the sending or the receiving queue manager). We need to have this exit in place since we require that the putting application receives an error if the intended message destination is unavailable. This way we can implement failover processing for our time-critical messages.
The exit is basically a simplified version of the sample exit provided (amqswlm0.c) with the server installation.
As a work around we defined an additional CLUSSDR (locally) and a CLUSCVR (on the destination) and our messages started flowing again.
Can anyone provide any insight as to why the exit might reject messages even though no channel events were logged? We are working to put some debug/trace information into the exit so that we can "see" what it's doing when it rejects messages, but I wanted to see if there's anyone out there with some experience in troubleshooting issues related to cluster workload exits.
Regards,
tonyB.
Where to get MQ5.1 client
Dear colleagues We are in process of integrating Domino5.0.11 with MQ. The only workable configuration for Domino 5.0.11 is JDK 1.1.8 and MQ5.1 client with MA88 supportpack. We can not download MQ5.1 and MA88 client since support for this fixpack expired while ago. Can anybody send MQ5.1 client for WindowsNT as well as related MA88 supportpack? Or point to download page? You may respond in private. TIA, George --- The information in this e-mail is intended solely for the addressee(s) named, and is confidential. Any other distribution, disclosure or copying is strictly prohibited. If you have received this communication in error, please reply by e-mail to the sender and delete or destroy all copies of this message. Les renseignements contenus dans le présent message électronique sont confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il est strictement interdit de distribuer ou de copier ce message. Si vous avez reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et effacer ou détruire toutes les copies du présent message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Cluster workload exit reject messages...
Title: Cluster workload exit reject messages... I have a Solaris based environment (5.8, all running WMQ 5.3 CSD05) with 6 queue managers involved across four hosts. All the queue managers are running. The issue I am having is that periodically the cluster workload exit is rejecting messages that are put to a remote cluster queue when it thinks that the channel to the remote manager is not up (state != Running). However, there is no corresponding channel event logged (on either the sending or the receiving queue manager). We need to have this exit in place since we require that the putting application receives an error if the intended message destination is unavailable. This way we can implement failover processing for our time-critical messages. The exit is basically a simplified version of the sample exit provided (amqswlm0.c) with the server installation. As a work around we defined an additional CLUSSDR (locally) and a CLUSCVR (on the destination) and our messages started flowing again. Can anyone provide any insight as to why the exit might reject messages even though no channel events were logged? We are working to put some debug/trace information into the exit so that we can "see" what it's doing when it rejects messages, but I wanted to see if there's anyone out there with some experience in troubleshooting issues related to cluster workload exits. Regards, tonyB.
Re: Clustering Question
>what are the drawbacks of just making one big cluster (external and >internal queue managers in the same cluster) as opposed to having a >"gateway" queue manager in overlapping clusters (which is recommended from >one document that I've read). Your firewall administration can get unwieldy. Rather than setting up a couple rules on the firewall, you now have to allow for the possibility of however many external QMgrs connecting to some number of internal QMgrs. So if you have three internal QMgrs talking to two external QMgrs you will need 6 sets of rules. You will also need to set up the firewall with no address translation among all the related hosts. When you set up a CLUSRCVR channel, both the external hosts and the internal hosts (the repositories at the very least) need to access it using the same IP address. >Aside from issues with server connection channels, what other security >issues should we be concerned with, and how would those issues be addressed? An MQ cluster is basically a Pub/Sub engine feeding a modified Command Server. When you advertise a queue or join a cluster, the configuration change is published to the repositories and propagated to anyone subscribed to those changes. When the published changes arrive at a repository or subscribing QMgr they are acted on by the modified Command Server which then builds channels or updates the local repository (whether full or partial). >From a security standpoint, you should be aware that any member of the cluster can publish these messages and your QMgrs will automatically respond. That means any QMgr which can join the cluster can become a full repository and/or alter the cluster's configuration. Also, any QMgr which can join the cluster can send messages anywhere throughout the cluster, whether the target queues are advertised to the cluster or not. So if your QMgrA is in the cluster I can send PCF messages to [EMAIL PROTECTED] and because they arrive over your CLUSRCVR channel, chances are they have full mqm admin privileges. Since the attacker can be a repository, they generally know enough about your cluster to go at least one hop beyond the cluster further into your MQ network. The gateway is meant to restrict that one-hop access to just the QMgrs the other side needs to know about. Remove the gateway and the one-hop now extends considerably further in. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ wrapper to new Java App Server World?
Hello Neil, You mentioned MDB in your question so I assumed you had some application server to run them; if you want to feed MDB directly from your application, you can of course use a single thread (and, hence, a static one). App servers use a pool and that standard JMS->appserver wiring to be able to feed MDBs with messages concurrently. Whether your app needs it or not is certainly up to you to decide. Regards, Pavel "Taylor, Neil" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/10/2004 09:07 AM Please respond to MQSeries List Pavel Thanks for your response. I think I can cut the JMS aspect out and just use the base java calls within my API Wrapper. If I just use the get with wait, and keep looping I can then notify the listeners (i.e. the end application) with the message. Get with wait is quite light-weight? Although this doe not fit my API model application initiated receive, it doesn't break it too much to fit to the java model. I saw the wrapper as a static class so not a pooled resource - not that I'm a J2EE or application server expect. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 18:20 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, To me it sounds as you will have to make your "API wrapper" your own JMS provider. You will most probably have to implement ConnectionConsumer and Session interfaces from there because this is how J2EE-compliant app servers support MDBs (they supply the implementation of ServerSession and ServerSessionPool and push messages through to Sessions they get from ServerSessions). I am not sure if any of them actually will be able to get messages for MDBs via any other interface. As for the asynchronous model of getting messages, you will probably have to create a special thread on a client side to call onMessage() methods on every registered listener (J2EE compliant app server does it with ServerSession's start() method) and that thread will push all messages through the listeners. This is how, I believe, any JMS Session is implemented (yes, I remember you want to keep JMS out of the loop I just refer to it as an example for implementing your wrapper. Pure MQ API only provides synchronous MQGET to receive messages). Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 11:23 AM Please respond to MQSeries List Thanks Pavel I am trying to keep mqseries and JMS out of the loop. My email below is not as clear as it could be - we have designed the API wrapper already, on the assumption of a receive call being made by the end-application. So we have a "receive" API call that we would expect an application to call, but Java's model is not to do this, but rather register with a listener and be notified of events. Thereby breaking the model. If anybody has experience in this area then please let me know. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 15:32 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ "Using Java" book for MQ part of the deal) and see if it works. Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper, th
Re: Clustering Question
It's not just your server connection channels you have to watch! As the external QMs will be connecting over the Extranet, how do you KNOW that they are who they claim to be and how are you going to ensure that other QMs don't join the cluster, or just connect to regular channels on your QMs now that you've opened the firewall for MQ traffic. If I'm Mr Evil Hacker and know the name and listener port for one of your cluster repositories, I can attach my QM to your cluster pretty sharply and put all sorts of messages to all sorts of queues, the possibilities are quite drool making for the bad guy. Lets see what I can think of quickly: Put interesting messages to SYSTEM.COMMAND.QUEUE on your QMs Find some interesting clusters queues and put some messages to them - you never know I might find a SWIFT queue and put some SWIFT format messages on there to pay me lots of ??. Fill up your cluster queues with invalid messages causing interesting Denial of Service problems. You can protect against most of this with a product like Data Secure for MQ, and to a lesser extent using SSL. HTH Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Warren Sent: 10 February 2004 16:21 To: [EMAIL PROTECTED] Subject: Clustering Question In a nutshell, we will be allowing an outside firm access to "put" to a few "internal" queue managers. In order to achieve some method of workload balancing, we wanted to use MQ's clustering capabilities. First of all, what are the drawbacks of just making one big cluster (external and internal queue managers in the same cluster) as opposed to having a "gateway" queue manager in overlapping clusters (which is recommended from one document that I've read). Aside from issues with server connection channels, what other security issues should we be concerned with, and how would those issues be addressed? -Warren Instructions for managing your mailing list 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
Clustering Question
In a nutshell, we will be allowing an outside firm access to "put" to a few "internal" queue managers. In order to achieve some method of workload balancing, we wanted to use MQ's clustering capabilities. First of all, what are the drawbacks of just making one big cluster (external and internal queue managers in the same cluster) as opposed to having a "gateway" queue manager in overlapping clusters (which is recommended from one document that I've read). Aside from issues with server connection channels, what other security issues should we be concerned with, and how would those issues be addressed? -Warren Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ 5.2 on OS/390 2.10 64-bit
We didn't have any problems. "Mauro, Samuel" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 02/10/2004 09:16 AM Please respond to "MQSeries List" To: [EMAIL PROTECTED] cc: Subject: MQ 5.2 on OS/390 2.10 64-bit Hello all. We are going to be implementing 64-bit mode on our 2.10 LPAR's as the first step of migration to z/OS. Has anyone out there done this, and/or are there any known MQ gotchas? Thanks in advance! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.
MQSeries 5.3 on Windows 2003
Title: MQSeries 5.3 on Windows 2003 Hi, Has anyone installed MQSeries 5.3 on Windows 2003 yet ? We want to upgrade from 5.2 on WinNT to 5.3 on W2K (or W2003) Thanks This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat.
IA09 supportpac (MQGet Plug-in) : usage on z/OS
Title: IA09 supportpac (MQGet Plug-in) : usage on z/OS Hi, Has anyone tried to compile the source for the MQGet Plug-in (support pac IA09) for use in WMQI on the z/OS platform ? Thanks, Pete Notice to recipient:The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority.
MQ 5.2 on OS/390 2.10 64-bit
Hello all. We are going to be implementing 64-bit mode on our 2.10 LPAR's as the first step of migration to z/OS. Has anyone out there done this, and/or are there any known MQ gotchas? Thanks in advance! Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ wrapper to new Java App Server World?
Pavel Thanks for your response. I think I can cut the JMS aspect out and just use the base java calls within my API Wrapper. If I just use the get with wait, and keep looping I can then notify the listeners (i.e. the end application) with the message. Get with wait is quite light-weight? Although this doe not fit my API model application initiated receive, it doesn't break it too much to fit to the java model. I saw the wrapper as a static class so not a pooled resource - not that I'm a J2EE or application server expect. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 18:20 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, To me it sounds as you will have to make your "API wrapper" your own JMS provider. You will most probably have to implement ConnectionConsumer and Session interfaces from there because this is how J2EE-compliant app servers support MDBs (they supply the implementation of ServerSession and ServerSessionPool and push messages through to Sessions they get from ServerSessions). I am not sure if any of them actually will be able to get messages for MDBs via any other interface. As for the asynchronous model of getting messages, you will probably have to create a special thread on a client side to call onMessage() methods on every registered listener (J2EE compliant app server does it with ServerSession's start() method) and that thread will push all messages through the listeners. This is how, I believe, any JMS Session is implemented (yes, I remember you want to keep JMS out of the loop I just refer to it as an example for implementing your wrapper. Pure MQ API only provides synchronous MQGET to receive messages). Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: Re: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 11:23 AM Please respond to MQSeries List Thanks Pavel I am trying to keep mqseries and JMS out of the loop. My email below is not as clear as it could be - we have designed the API wrapper already, on the assumption of a receive call being made by the end-application. So we have a "receive" API call that we would expect an application to call, but Java's model is not to do this, but rather register with a listener and be notified of events. Thereby breaking the model. If anybody has experience in this area then please let me know. Regards Neil -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: 09 February 2004 15:32 To: [EMAIL PROTECTED] Subject: Re: MQ wrapper to new Java App Server World? Hello Neil, I have never tried it with MQ JMS provider, but looking in the doucmentation, it does include its own implementation of ConnectionConsumer (which is exactly the facility intended for an application server to push messages into its MessageListeners, which MDBs are). So I would recommend you to configure your appServer to use MQ as an external JMS provider (see MQ "Using Java" book for MQ part of the deal) and see if it works. Hope this will help, Pavel "Taylor, Neil" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] EQUEST.COM> cc: Sent by: MQSeries Subject: MQ wrapper to new Java App Server World? List <[EMAIL PROTECTED] C.AT> 02/09/2004 05:23 AM Please respond to MQSeries List Hi I was wondering if anyone had experience of building an MQ wrapper, that was then to be implemented in the Java/ EJB world. Where Message Driven Beans are the norm and expect to be event driven. How has this changed the model? For instance we have a receive API call that we use to abstract the MQGet functionality. However, this assumes a polling by the application calling the API. But with the MDB the expected mode is of message arrival "waking" the application and "giving" it the message directly. Hence the MQ Wrapper is bypassed. Any views? Regards Neil -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Us
unsubscribe
. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Trigger
A big thanks to everyone's assistance! John Dawson -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 6:59 PM To: [EMAIL PROTECTED] Subject:Re: [Maybe Spam] Trigger I see. I don't think you need to do anything to restart the trigger mechanism because you haven't done anything to disable it (at least nothing that you mentioned). I still don't quite understand the point of put-disabling the triggered queue, but that's not really the issue. Put-disabling a triggered queue will certainly stop the flow of messages, but I'm not aware that it does anything to affect the triggering mechanism, itself. You claim that your triggered program will process the queue until it gets a 2033. That's exactly what it should do. But then you say there's a chance the triggered app does not get the 2033 return code. Why is that? (Of course, there's always that possibility, I just don't see how it relates to pur-disabling the triggered queue). And what does the program do then? If it keeps trying for a 2033, then you don't need to re-trigger it. If it quits, then it will just retrigger immediately (aka "poison message loop") when there are messages on the queue. Sounds to me like maybe you need to rethink the error-handling in the triggered application. Regards, Dennis -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: Re: [Maybe Spam] Trigger Dennis, There is a trigger queue receiving messages. The queue is trigger on first. The logic of the triggered program is that once triggered, it will process all the messages until receiving a return code of 2033. At times after getting the application message, there will be a need to prevent any additional messages from being 'put' to the queue. So, the triggered program will 'put' disable the queue. When it does the 'put' disabled, there's a chance that the program did not receive the 2033 return code and messages are remaining on the queue. My question is, if there are messages that remained on the queue while the queue was 'put' disabled, will those messages that remain on the queue cause the trigger mechanism to restart. Or, will the trigger need to be turned off and then turned backed on to restart the trigger mechanism, once the queue has been 'put' enabled? Thanks, John Dawson -Original Message- From: Miller, Dennis [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 12:49 PM To: [EMAIL PROTECTED] Subject:Re: [Maybe Spam] Trigger John, Unfortunately, I cannot follow your question. Maybe I just don't understand what 'puts' is. If a queue is put-disabled, then no more messages can be queued there. If a program loops until 2033, then that means all queued messages have been removed. So what do you mean by "because of this, messages will remain on the queue". Also, it's not that common to put-disable a triggered queue. Sort of defeats the purpose of queuing. Please better explain what you are trying to accomplish. -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 7:21 AM To: [EMAIL PROTECTED] Subject: [Maybe Spam] Trigger Hey Folks, I have a triggered queue, triggering on first. The 'puts' for the queue is disabled because the program, acting upon a message, has to stop the processing, inside the loop that is getting messages until a return code of 2033. Because of this, messages will remain on the queue. When the 'puts' on the queue is re-enabled, will the remaining messages on the queue force the trigger to start again or will it take a new message arriving on the queue to start the triggering. What if the triggering is turned off and then on at the same time as the 'puts' are re-enabled? Thanks everyone, John Dawson Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Anybody used the OAGIS XML standards for their applications?
Title: Message Has anybody ever used the OAGIS standards for their XML structures? What do people think about these standards? Are they in significant use or do they appear to look good on paper, but not quite so practical in the real world...) Anybody have any useful links to a critique of these standards? Details on the OAGIS XML standards can be found at http://www.openapplications.org/default.htm Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd *** 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 addressee, any disclosure, reproduction, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed.
