Opinion please
The question involves two QMGRs that each have access to some shared queues. High availability customers connect from remote QMGRs to one of these QMGRs. When the active QMGR fails, we want a non-disruptive failover to the other QMGR. Is it possible to define shared and non-shared queues within the same QMGR? It is my impression that if one did this, then any messages coming in which are destined to the non-shared queues in the QMGR that has failed, will end up going to the dead letter queue until that QMGR has been restarted. For this reason, I feel it would be better to define no non-shared queues in the two QMGRs that contain the shared queues.appreciate anyones opinion as regard shared...non-shared.. Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland Office +353 21 2309331 Mobile +353 86 1713777
Re: Data conversion on mainframe
Thanks Rebecca. I am tracing out the data and it looks fine... I think this is an environment or linkage issue but without clarification from IBM I think I will have to solve this problem somewhere else in our environment. Regards Darren From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Date: Mon, 17 Mar 2003 08:14:46 -0500 Darren, sounds like it's time for something drastic. How about adding some kind a dump/snap just before your call. Or my personal favorite -- simply zap the preceding instruction to x'00' and force an S0C1 (or whatever it's called in CICS). Not pretty, but generally pretty effective. Or you can try adding a WTO and wrote out the data... Rebecca -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 5:25 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Rick, I have a rather unsophisticated environment - CEDF is the limit of my online debugging facilities and this doesn't step into the MQXCNVC call. The handle is fine for calls that follow the MQXCNVC call... wonder if it is a problem passing the parameters... Cheers Darren >From: Rick Tsujimoto <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Data conversion on mainframe >Date: Fri, 14 Mar 2003 15:37:52 -0500 > >Darren, > >If you have an online debugger, e.g. Intertest, just step throught the code >and see where the handle gets whacked. > > > > > Darren Douch > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > COM> cc: > Sent by: Subject: Re: Data >conversion on mainframe > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 03/14/2003 02:51 > PM > Please respond > to MQSeries List > > > > > >Thanks Rebecca. I am already setting my Hcon to the supplied default (and >using that same handle on other MQ calls quite happily before and after the >MQXCNVC call). > >Might have to resort to trying the samples (assembler only unfortunately) >and then seeing if I can link to them from C... certainly a more painful >route. Maybe Morag will post a response and save the day :) > >Cheers >Darren. > >- Original Message - >From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, March 14, 2003 4:20 PM >Subject: Re: Data conversion on mainframe > > > > Darren, while you don't have to do the MQCONN, I believe that there's >still > > a connection handle (after all, it's a parm you need to specify on your > > MQOPEN). Check what you have this set to (I think it's MQHC_DEF_HCONN >for > > CICS when you don't so the MQCONN) and that you haven't overwritten it. >HTH > > -- Rebecca > > > > Rebecca Bullock > > Computer Sciences Corporation > > MFCoE/Newark CS Team > > > > Educational Testing Service Account > > Princeton, NJ 08541 > > > > email: [EMAIL PROTECTED] or [EMAIL PROTECTED] > > > > > > -Original Message- > > From: Darren Douch [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 14, 2003 8:20 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Data conversion on mainframe > > > > > > Ian and others... > > > > I can't argue about MQGET - it works as described in the manuals. But I > > have a scenario where I can't use it... long story short is that I have >a > > couple of chained data structures in front of the message data itself, >plus > > I don't know at the time of the GET whether I want to convert it >'properly' > > (using MQ's codepage support) or improperly (using some homegrown >conversion > > tables that are needed to keep a downstream application happy). > > > > I've made a bit of progress - managed to build the module now (whether > > correctly I don't know) - but get 2018 - invalid connection handle - >which > > is a bit odd because CICS apps don't really need / use a connection >handle. > > > > Any more offers? > > > > Cheers > > Darren. > > > > > > > > > > > > > > >From: Ian Metcalfe <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: Data conversion on mainframe > > >Date: Fri, 14 Mar 2003 21:59:53 +1100 > > > > > >Hey Darren, > > > > > >If I understand what you're asking correctly, I believe the recommended >way > > >is to simply use MQGMO_CONVERT on any MQGET calls on queues that may > > >contain > > >messages from other platforms. If it's a text message type, like MQSTR >for > > >example, it'll automatically be converted to the appropriate type for >the > > >platform you're on. > > > > > >This works in all cases in my experience, and manually converting >within > > >the > > >application seems to be a bit of a waste of effort to me. > >
Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first
From the Intercommunication Guide. MAYBE?? bobbee Heartbeat interval (HBINT) This attribute applies to WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris,and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, Compaq NonStop Kernel, Compaq OpenVMS Alpha, and OS/2 Warp, and for WebSphere MQ for z/OS without CICS. You can specify the approximate time between heartbeat flows that are to be passed from a sending MCA when there are no messages on the transmission queue. Heartbeat flows unblock the receiving MCA, which is waiting for messages to arrive or for the disconnect interval to expire. When the receiving MCA is unblocked it can disconnect the channel without waiting for the disconnect interval to expire. Heartbeat flows also free any storage buffers that have been allocated for large messages and close any queues that have been left open at the receiving end of the channel. The value is in seconds and must be in the range 0 through 999 999. A value of zero means that no heartbeat flows are to be sent. The default value is 300. To be most useful, the value should be significantly less than the disconnect interval value. This attribute is valid for sender, cluster-sender, server, receiver, cluster-receiver, and requester channels. Other than on z/OS and OS/400, it also applies to server-connection and client-connection channels. On these channels, heartbeats flow when a server MCA has issued an MQGET command with the WAIT option on behalf of a client application. From: "Keith A. Hessong" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Date: Mon, 17 Mar 2003 17:20:21 -0500 We have tried ADOPTMCA to solve our problem and it didn't do any good. We haven't tried ADOPTNEWMCA though. Keith -Original Message- From: Crupi, Margherita [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 4:20 PM To: [EMAIL PROTECTED] Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Could the MQ channel ADOPTMCA* & ADOPTNEWMCA parms help you in respect to automatically retry channel operations -Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Saturday, 15 March 2003 5:45 AM To: [EMAIL PROTECTED] Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Keith, by "bridge" are you referring to the channels? I don't know if this will help, but a long time ago, we had something that sounds vaguely similar (although it was a Solaris system where you have Windows). What we ended up doing is having the dist. side: 1) Send STOP CHANNEL commands to the mainframe telling it to stop the sender channel to the sun side 2) Issue STOP CHANNEL commands for the sender channels on the distributed side. Then at restart: 1) Send START CHANNEL commands to the mainframe telling it to restart its sender channels 2) Issue START CHANNEL for the local sender The only thing you have to watch for is if you WANT the channels to be down and you do a reboot, although that could be scripted around. Since we have no Windows qmgrs, I don't know if you can do something similar, but at least you now got a response :-) Good luck! HTH -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Keith A. Hessong [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 12:12 PM To: [EMAIL PROTECTED] Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Greetings: I am trying this again. I didn't get any responses from my first attempt at sending this issue to the list. Thanks, Keith Hessong Senior Programmer/Analyst Golden Rule Insurance Company -Original Message- From: Keith A. Hessong [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 10:32 AM To: [EMAIL PROTECTED] Subject: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Greetings: My shop is currently experiencing a problem with MQ Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed side without dropping the bridge first. My shop ends up having at least one of our mainframe connections showing up on the distributed side as "PENDING". Our environment is as follows: Distributed Side: MQ Series Version 5.2 MSMQ MQ Series Bridge within Host Integration Server WINDOWS 2000 MSMQ Service Pack 3 Mainfr
MQ and XA
Hi, does anyone know of any examples of using the command rsvmqtrn when trying to resolve an in-doubt state on the Queue manager? thanks Jay
[no subject]
Is it possible for a MQInput Node( or any of the primitive nodes) in WMQI v2.1 to do a search on an input q, containing a number of messages and select a msg with a specific MsgId ?. The msgId is not a static one.
.Net VB Api
Hello, I'm willing to upgrade my VB 6 code to VB .net without changing my MQ api calls. The SupportPacs provided by Kolban and IBM supportpac page (MA7P) do not match for what i'm looking for. Those SupportPacs provides me an API that is more like the ACTVEX api. when I used VB 6, I could handle the HCONN for example. Is there some way i could work with VB .NET with the old MQ api (not the activex) ? Lior
