Re: Fish outa water
Responses intermixed below... > -Original Message- > From: Lovett, Alan J [mailto:[EMAIL PROTECTED] > Sent: Monday, February 02, 2004 5:08 AM > To: [EMAIL PROTECTED] > Subject: Re: Fish outa water > > > A few points: > > 1) The client server feature on S/390 is indeed chargeable. Thanks for clearing that up for me! > 2) Client programs can (and should!) do their stuff inside a > recoverable unit of work. So synchronisation shouldn't be a > problem, or at > least no more than with local bindings. Two points here: synchronization and difference between local vs. client bindings. I'll address these separately. Ok, so you've done a bunch of PUT and GET under syncpoint, you issue a COMMIT and get a 2009 MQRC_CONNECTION_BROKEN. How do you know whether the connection was broken on the way to the QMgr or if the QMgr executed the COMMIT and the response never made it back to the client? To answer that question in code is the essence of recovering state. If the mainframe application will accept duplicate transactions the program can simply repeat any PUTs that were under syncpoint when the 2009 occurred. Similarly, if the client app accepts dupes, any GET calls that were backed out can simply be reprocessed. In order for synchronization to not be a problem, the program code would have to take these possibilities into account. Locally bound programs won't get a 2009 return code. If the local COMMIT fails, a more descriptive return code is given and the program knows with a high degree of certainty whether the COMMIT was successful. The client program receiving a 2009 return code enjoys no such certainty. There is a possibility that the connection broke before the client agent received the COMMIT in which case the UOW will be backed out. There is also the possibility that the client agent successfully executed the COMMIT but lost the connection before sending the return code, in which case the UOW will have been completed. In either case the client program receives a 2009 issued from the local MQ client stub. There is in fact a rather profound distinction to be made between a program bound locally to a QMgr and one operating as a client and an agent separated by an arbitrary number of network nodes. > 3) The assertions on security leave out the possibility > of altering > objects with MQI commands, which can be sent over > sender/receiver channels. > If that is a problem, you have a problem regardless of the > connection type. AFAIK, the SDR/RCVR channel agents will only deliver messages to a queue and must use the command queue to alter any objects. On the other hand, a SVRCONN channel agent has the ability to alter objects directly. There are a number of protective measures, some of which apply to both connection types (MCAUSER, setmqaut) and others which are effective against one and not the other (turning off the Command Server). Hopefully, your strategies for protecting SVRCONN channels are different from your strategies for protecting RCVR channels and take this difference into account. -- T.Rob > Regards, Alan Instructions for managing your mailing list 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: Fish outa water
> 2) Client programs can (and should!) do their > stuff inside a > recoverable unit of work. So synchronisation > shouldn't be a problem, or at > least no more than with local bindings. This is not true. I agree with T.Rob's explanation on this point. Ruzi --- "Lovett, Alan J" <[EMAIL PROTECTED]> wrote: > A few points: > > 1) The client server feature on S/390 is indeed > chargeable. > > 2) Client programs can (and should!) do their > stuff inside a > recoverable unit of work. So synchronisation > shouldn't be a problem, or at > least no more than with local bindings. > > 3) The assertions on security leave out the > possibility of altering > objects with MQI commands, which can be sent over > sender/receiver channels. > If that is a problem, you have a problem regardless > of the connection type. > > Regards, Alan > > > -Original Message- > From: MQSeries List > [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, > T. Rob > Sent: 30 January 2004 21:59 > To: [EMAIL PROTECTED] > Subject: Re: Fish outa water > > > Jerry, > > There are several JMS providers in addition to WMQ > but none, that I know of > anyway, that will pull WMQ messages out of the > mainframe. Now, the manager > in question may be referring to the ability of WMQ > JMS to run over a client > connection to connect to the mainframe. This would > in fact be free for the > Solaris machine but I'm not sure if the Mainframe > client connect feature is > a licensed component. Someone else on the list is > sure to answer that one. > > In any case, migration to a client when you've > already invested in the MQ > Server is questionable. The client introduces a few > new issues you will > need to deal with. First of all, you will be using > a synchronous connection > to talk with an agent at the QMgr which then talks > to MQ. If the connection > breaks in between issuance of an API call (GET, PUT, > COMMIT, etc.) you have > no way of knowing whether the call was successful or > not. To deal with > this, your application needs to have some way of > recovering state after a > broken connection. > > The other issue is security. A server-to-server > channel will never do > anything other than deliver messages. A > client-to-server channel has the > ability to alter WMQ objects and, in its default > configuration, send PCF > messages to the MQ command server. To secure the > channel, you will need to > use SSL or a channel exit and set the MCAUSER at the > mainframe side. > > It seems like this is a lot of effort to go through > in order to save a few > thousand dollars on an application that, based on > your email, isn't broken. > > -- T.Rob > > -Original Message- > From: Cergol, Jerry [mailto:[EMAIL PROTECTED] > Sent: Friday, January 30, 2004 3:19 PM > To: [EMAIL PROTECTED] > Subject: Fish outa water > > > I've been running WMQ for z/OS 5.3 on my IBM > Mainframe and sending > relatively medium-size and moderately frequent > persistent messages outbound > to a Sun Solaris running WMQ 5.3. The Sun Solaris > manager wants to jetison > WMQ altogether because it is expensive relative to > its utilization. He > mentioned a publish/subscribe type architecture what > would use Java > Messaging Services on the Sun/Solaris to pull data > over from z/OS WMQ. I've > been implementing and maintaining WMQ on both the > mainframe and the Sun but, > being strictly limited to dealing with IBM z/OS > components, I have no clue > as to where to start to get a handle on the > requirements for a JMS-WMQ > design. Can anyone point me at a manual or reference > as a starting point? > Thanks in advance. > > Jerry Cergol > Cleveland Clinic Foundation > IBM Mainframe System Support > > > > > > -- > Confidentiality Note: This message is intended for > use only by the > individual or entity to which it is addressed and > may contain information > that is privileged, confidential, and exempt from > disclosure under > applicable law. If the reader of this message is > not the intended recipient > or the employee or agent responsible for delivering > the message to the > intended recipient, you are hereby notified that any > dissemination, > distribution or copying of this communication is > strictly prohibited. If > you have received this communication in error, > please contact the sender > immediately and destroy the material in its > entirety, whether electronic or > hard
Re: Fish outa water
A few points: 1) The client server feature on S/390 is indeed chargeable. 2) Client programs can (and should!) do their stuff inside a recoverable unit of work. So synchronisation shouldn't be a problem, or at least no more than with local bindings. 3) The assertions on security leave out the possibility of altering objects with MQI commands, which can be sent over sender/receiver channels. If that is a problem, you have a problem regardless of the connection type. Regards, Alan -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Wyatt, T. Rob Sent: 30 January 2004 21:59 To: [EMAIL PROTECTED] Subject: Re: Fish outa water Jerry, There are several JMS providers in addition to WMQ but none, that I know of anyway, that will pull WMQ messages out of the mainframe. Now, the manager in question may be referring to the ability of WMQ JMS to run over a client connection to connect to the mainframe. This would in fact be free for the Solaris machine but I'm not sure if the Mainframe client connect feature is a licensed component. Someone else on the list is sure to answer that one. In any case, migration to a client when you've already invested in the MQ Server is questionable. The client introduces a few new issues you will need to deal with. First of all, you will be using a synchronous connection to talk with an agent at the QMgr which then talks to MQ. If the connection breaks in between issuance of an API call (GET, PUT, COMMIT, etc.) you have no way of knowing whether the call was successful or not. To deal with this, your application needs to have some way of recovering state after a broken connection. The other issue is security. A server-to-server channel will never do anything other than deliver messages. A client-to-server channel has the ability to alter WMQ objects and, in its default configuration, send PCF messages to the MQ command server. To secure the channel, you will need to use SSL or a channel exit and set the MCAUSER at the mainframe side. It seems like this is a lot of effort to go through in order to save a few thousand dollars on an application that, based on your email, isn't broken. -- T.Rob -Original Message- From: Cergol, Jerry [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: Fish outa water I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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 Instructions for managing your mailing list 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: Fish outa water
Jerry, There are several JMS providers in addition to WMQ but none, that I know of anyway, that will pull WMQ messages out of the mainframe. Now, the manager in question may be referring to the ability of WMQ JMS to run over a client connection to connect to the mainframe. This would in fact be free for the Solaris machine but I'm not sure if the Mainframe client connect feature is a licensed component. Someone else on the list is sure to answer that one. In any case, migration to a client when you've already invested in the MQ Server is questionable. The client introduces a few new issues you will need to deal with. First of all, you will be using a synchronous connection to talk with an agent at the QMgr which then talks to MQ. If the connection breaks in between issuance of an API call (GET, PUT, COMMIT, etc.) you have no way of knowing whether the call was successful or not. To deal with this, your application needs to have some way of recovering state after a broken connection. The other issue is security. A server-to-server channel will never do anything other than deliver messages. A client-to-server channel has the ability to alter WMQ objects and, in its default configuration, send PCF messages to the MQ command server. To secure the channel, you will need to use SSL or a channel exit and set the MCAUSER at the mainframe side. It seems like this is a lot of effort to go through in order to save a few thousand dollars on an application that, based on your email, isn't broken. -- T.Rob -Original Message- From: Cergol, Jerry [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 3:19 PM To: [EMAIL PROTECTED] Subject: Fish outa water I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you. == Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Fish outa water
Jerry, The following link will take you to where you can download the PDF manual for "WebSphere MQ Using Java". Within this manual you will find the JMS API described. http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=SC34606602# Cergol, Jerry wrote: I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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 -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Fish outa water
I've been running WMQ for z/OS 5.3 on my IBM Mainframe and sending relatively medium-size and moderately frequent persistent messages outbound to a Sun Solaris running WMQ 5.3. The Sun Solaris manager wants to jetison WMQ altogether because it is expensive relative to its utilization. He mentioned a publish/subscribe type architecture what would use Java Messaging Services on the Sun/Solaris to pull data over from z/OS WMQ. I've been implementing and maintaining WMQ on both the mainframe and the Sun but, being strictly limited to dealing with IBM z/OS components, I have no clue as to where to start to get a handle on the requirements for a JMS-WMQ design. Can anyone point me at a manual or reference as a starting point? Thanks in advance. Jerry Cergol Cleveland Clinic Foundation IBM Mainframe System Support -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. 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
