Re: Register IBM MSCS Resource Type with MSCS - wmq5.3
thanks arlen. - Original Message - From: Williams, Arlen To: jesse h. goode jr. Sent: Friday, March 21, 2003 8:25 PM Subject: RE: Register IBM MSCS Resource Type with MSCS - wmq5.3 From Chapter 13 of the System Administration Guide - 'haregtyp /r' at the command prompt and reboot the box. The manual does not say to reboot, but I couldn't get it to work without it. Arlen Williams EDS -Original Message-From: jesse h. goode jr. [mailto:[EMAIL PROTECTED]Sent: Friday, March 21, 2003 5:21 PMTo: [EMAIL PROTECTED]Subject: Register IBM MSCS Resource Type with MSCS - wmq5.3 wmq5.3 was installed on (2) individual nodes. These nodes were then MSCS Clustered. The IBM MSCS Resource Type is not listed as one of the available types. ( i.e. the .dll is not registered with MSCS ) . Anyone know how to get it registered? jesse goode jrvalero energy corporation[EMAIL PROTECTED]
Re: Increase size of error logs
Hi Aatush, I would assume that you'd have to set a global environment variable (ControlPanel->System) on Windoze platforms as well, wouldn't you? Just a guess, haven't tried it. Peace, Stefan From: "Aatush Desai(PIPEX)" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Increase size of error logs Date: Fri, 21 Mar 2003 22:44:14 - RE: Increase size of error logsMy friend found the following on IBMLINK:- 1. ERROR DESCRIPTION: Customer requests that the size of the error logs be either larger or (better) changeable. The current size defaults to 256Kb but he wants to be able to manually change the default size to as large as 1 megabyte in size for each log file. PROBLEM SUMMARY: The problem has been fixed. . New function has been provided to allow the user to specify the maximum size of error log files (amqerr0x.log) with a new environment variable,MQMAXERRORLOGSIZE,(the default is 256K): . ,MQMAXERRORLOGSIZE=x, . where x is the approximate file size in bytes. . 2. PROBLEM SUMMARY: Cust wanted to know how to change error logs size. SOLUTION: In order to change the error log size under the three directories that MQSeries uses to log errors in, he needs to use the following environment variable globally: ,MQMAXERRORLOGSIZE=100,where 100 is the maximum. So for UNIX platforms you set the environment variable, but does anyone know where to set the registry value on NT??? Aatush - Original Message - From: Chan, John To: [EMAIL PROTECTED] Sent: Thursday, March 13, 2003 7:14 PM Subject: Re: Increase size of error logs Hey dudes, If you can change those AMQSERR01 log file sizes and number of those log files, I love to hear about it. JC -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Increase size of error logs The properities page increases the size for the "ACTIVE" logs, PRIM and SEC. The LOG in the EMAIL is the ERROR Message Log. I not sure if this is covered under Properties. bobbee >From: "Marty G. Trice" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Increase size of error logs >Date: Thu, 13 Mar 2003 08:45:07 -0500 > > > >My Friend, > >Goto to START | PROGRAM | IBM MQSERIES 5.2| MQSERIES SERVICES. From >this point, right click on the qmgr that you plan to modify, and goto >properties >| >log. Also, the LogPageSizes can only be adjusted by recreating the >qmgr and initializing the needed size. > >Marty G. Trice >WebSphere MQ/MQI Administrator >Sara Lee Business Services - EAI Group >[EMAIL PROTECTED] >336.519.2939 > > >(Embedded image moved to file: pic26924.pcx) > > > > > > "Aatush > Desai(PIPEX)"To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED]cc: > .PIPEX.COM> Subject: Increase size of >error logs > Sent by: MQSeries > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 03/12/2003 07:12 > PM > Please respond to > MQSeries List > > > > > > > >Hi... > >MQ error logs (amqerr01.log..etc) are cut when they go over 256KB. >MQ also keeps 3 logs. > >Does anyone know either how to increase the size of the logs or the >number of logs. Platform if NT, v5.2 and above. > > > >Thanks Aatus > ><< pic26924.pcx >> _ Add photos to your e-mail 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 _ 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
Register IBM MSCS Resource Type with MSCS - wmq5.3
wmq5.3 was installed on (2) individual nodes. These nodes were then MSCS Clustered. The IBM MSCS Resource Type is not listed as one of the available types. ( i.e. the .dll is not registered with MSCS ) . Anyone know how to get it registered? jesse goode jrvalero energy corporation[EMAIL PROTECTED]
Re: Increase size of error logs
Title: RE: Increase size of error logs My friend found the following on IBMLINK:- 1. ERROR DESCRIPTION: Customer requests that the size of the error logs be either larger or (better) changeable. The current size defaults to 256Kb but he wants to be able to manually change the default size to as large as 1 megabyte in size for each log file. PROBLEM SUMMARY: The problem has been fixed. . New function has been provided to allow the user to specify the maximum size of error log files (amqerr0x.log) with a new environment variable,MQMAXERRORLOGSIZE,(the default is 256K): . ,MQMAXERRORLOGSIZE=x, . where x is the approximate file size in bytes. .2. PROBLEM SUMMARY: Cust wanted to know how to change error logs size. SOLUTION: In order to change the error log size under the three directories that MQSeries uses to log errors in, he needs to use the following environment variable globally: ,MQMAXERRORLOGSIZE=100,where 100 is the maximum. So for UNIX platforms you set the environment variable, but does anyone know where to set the registry value on NT??? Aatush - Original Message - From: Chan, John To: [EMAIL PROTECTED] Sent: Thursday, March 13, 2003 7:14 PM Subject: Re: Increase size of error logs Hey dudes, If you can change those AMQSERR01 log file sizes and number of those log files, I love to hear about it. JC -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 13, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Increase size of error logs The properities page increases the size for the "ACTIVE" logs, PRIM and SEC. The LOG in the EMAIL is the ERROR Message Log. I not sure if this is covered under Properties. bobbee >From: "Marty G. Trice" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Increase size of error logs >Date: Thu, 13 Mar 2003 08:45:07 -0500 > > > >My Friend, > >Goto to START | PROGRAM | IBM MQSERIES 5.2| MQSERIES SERVICES. From >this point, right click on the qmgr that you plan to modify, and goto >properties >| >log. Also, the LogPageSizes can only be adjusted by recreating the >qmgr and initializing the needed size. > >Marty G. Trice >WebSphere MQ/MQI Administrator >Sara Lee Business Services - EAI Group >[EMAIL PROTECTED] >336.519.2939 > > >(Embedded image moved to file: pic26924.pcx) > > > > > > "Aatush > Desai(PIPEX)" To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > .PIPEX.COM> Subject: Increase size of >error logs > Sent by: MQSeries > List > <[EMAIL PROTECTED] > n.AC.AT> > > > 03/12/2003 07:12 > PM > Please respond to > MQSeries List > > > > > > > >Hi... > >MQ error logs (amqerr01.log..etc) are cut when they go over 256KB. >MQ also keeps 3 logs. > >Does anyone know either how to increase the size of the logs or the >number of logs. Platform if NT, v5.2 and above. > > > >Thanks Aatus > ><< pic26924.pcx >> _ Add photos to your e-mail 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: MQ Multithreading
Thanks Darren !! -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 3:28 PM To: [EMAIL PROTECTED] Subject: Re: MQ Multithreading Dean MQ is inherently asynchronous - your CICS and AIX apps will not be talking directly to each other in the way that they do with LU6.2 - although message transfer times can be quick enough to make MQ look synchronous. Your apps can have any number of threads getting / putting msgs at the same time though. Regards Darren. - Original Message - From: "Dean Montevago" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 4:38 PM Subject: MQ Multithreading > Hi, > > We have a CICS (S390 <==> AIX) LU6.2 application that is multithreaded with > up to 8 tranactions. This is being converted to MQ. Can you do > multithreading with MQ ? If so, any ideas on how to go about it. > > TIA > Dean > > Dean Montevago > Sr. Software Specialist > Visiting Nurse Service of N.Y. > > phone : (212) 290 - 0543 > 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 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 Multithreading
Dean MQ is inherently asynchronous - your CICS and AIX apps will not be talking directly to each other in the way that they do with LU6.2 - although message transfer times can be quick enough to make MQ look synchronous. Your apps can have any number of threads getting / putting msgs at the same time though. Regards Darren. - Original Message - From: "Dean Montevago" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 4:38 PM Subject: MQ Multithreading > Hi, > > We have a CICS (S390 <==> AIX) LU6.2 application that is multithreaded with > up to 8 tranactions. This is being converted to MQ. Can you do > multithreading with MQ ? If so, any ideas on how to go about it. > > TIA > Dean > > Dean Montevago > Sr. Software Specialist > Visiting Nurse Service of N.Y. > > phone : (212) 290 - 0543 > 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: Running different versions of MQ
Title: Running different versions of MQ Stewart: We are running the same configuration. Early Code is loaded in the LPA, so you’d include your thqual.SCSQLINK library in an LPALSTxx member of SYS1.PARMLIB. This library does not have to be in linklist. As for your thqual.SCSQAUTH, its how you want to migrate to your new release that will dictate what you do. We’ve left the old 1.2 thqual.SCSQAUTH in our linklist and steplib to the new thqual.SCSQAUTH for those programs running 5.3 MQSeries. For Clists I picked up a little utility called STEPLIB to allocate the appropriate SCSQANLE SCSQAUTH libraries based on the release we’re connecting to. Hope this helps .. Nick Miokovic Disney Worldwide Services Maingate Office Complex 3020 #1029 PO Box 1 Lake Buena Vista, Fl 32830 Phone: (407)390-5117 Tie Line: 8-298-5117 Pager: (407)643-6999 Database and Online Support: 8-298-5421 "This communication is confidential, intended only for the named recipient(s) above and may contain trade secrets or other information that is exempt from disclosure under applicable law. Any use, dissemination, distribution or copying of this communication by anyone other than the named recipient(s) is strictly prohibited. If you have received this communication in error, please immediately notify me by calling (407) 390-5117. Thank you." -Original Message- From: Herd, Stewart [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 11:49 AM To: [EMAIL PROTECTED] Subject: Running different versions of MQ Am I correct in my assumption..? We have a client who has stated that they would like to be able to run MQ 1.2 and MQ 5.3 simultaneously on the same LPAR. I had read about this in the MQ 5.3 Systems Setup Guide, and I just reviewed it again. This requires that the Early Code of the latest version be added to the Link List first, and then execution of multiple versions should be possible. However, the 'SYS1.SCSQAUTH' library is currently in the Link List. It appears this will have to be removed from the Link List and added to every batch region that accesses MQ. I believe it is already in all of the CICS regions. If I understand it correctly, the two libraries that represent the Early Code are 'SYS1.SCSQLINK' and 'SYS1.SCSQSNLE'. 'SYS1.SCSQAUTH' is dynamically allocated within the clist that runs the ISPF MQ panel. However, due to other MQ programs called while using ISPF, I think 'SYS1.SCSQAUTH' will need to be added to the STEPLIBs of all the TSOPROCs also. Thanks in advance Stewart
Re: Data conversion on mainframe
Ruzi the connection handle in a CICS app isn't a 'normal' connection handle - it is actually the CICS region itself is connected to the qmgr, CICS just lets the application use one of these handles. The contents of the handle are 0 - before and after - and that is normal. I really think this is a problem with the MQXCNVC support (like maybe it isn't supported from C/CICS) rather than it being an application problem. Thanks Darren. - Original Message - From: "Ruzi R" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 19, 2003 5:02 AM Subject: Re: Data conversion on mainframe > Darren, > > Why don't you try to write the handle to a TS queue(s) > before the suspected call(s)? You can then view the > contents of the queue(s). > > Regards, > > Ruzi > --- Darren Douch <[EMAIL PROTECTED]> wrote: > > 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 >
Re: Candle Command Centre and MQSeries
What do you have specified as the interval for the situation? We very seldom see in-doubts thru CCC, but we set the interval to 1 minute. Glen Shubert "Herd, Stewart" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 03/21/2003 11:22 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Candle Command Centre and MQSeries First let me explain that in the MTSP QMGR we have MQ channels going out to: AAR_MTSP.AAR_AARP AAR_MTSP.AAR_MTST AAR_MTSP.CCRA_TITAN AAR_MTSP.CNR_MCP2 AAR_MTSP.CPR_MQP2 MTSP.TO.MQOHUXP1.BIN MTSP.USCS_MQB1 SGRC.MTSP.ZCC1 All except the top 2 are in remote networks. These are all SNA except for the Sun Solaris. I have the batch size set to 500 for the channels to the other in-house QMGRs as the volume is very high. The volume to MTST is not high, though. If you look inside the CCC task CANSCMSA at the DD RKLVLOG, you can see the activity. The issue is that the CCC is sending out false channel indoubt alerts, and I think they are always for the high activity channels between MTSP and AARP. Sometimes the indoubt period is perceived to be short, but here is one that is not: 09:48:09.14 KO41041 Enterprisesituation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is true. 09:53:09.11 KO41042 Enterprisesituation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is no longer true. From this message, you cannot know which channel it MTSP it was. These are showing up as red button alerts on the CCC monitor. When one of these long ones occurs, you can look at MQ with the MQ panel, and the channel is NOT in an indoubt status. I have turned off the channel events going to 'SYSTEM.ADMIN.CHANNEL.EVENT', which the CCC reads, but it is gather this info by observing the QMGR in a non-intrusive way. That's what Candle calls it. So, this is the issue. Operations is being bombarded with channel indoubt alerts, which in my opinion are not actually occurring. Has anyone had a similar experience or any ideas? Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland Office +353 21 2309331 Mobile +353 86 1713777
FW: Candle Command Centre and MQSeries
Stewart, I've also seen Candle throw out alerts about the channel in doubt status. What I learned was that everytime MQ attempts to start a channel there is small period of time when the channel will be in doubt. This occurs as the MCA's work through their hand shaking. I was not able to figure out though why Candle seemed to catch some of these situations and not others. The only effective way I found to stop Candle from sending the alerts was to disable the situation in Candle . I still have the Channel Stopped situation being monitored by Candle and that has been sufficient for my purposes. Don Thomas EDS - PASC ( Phone: +01-412-893-1659 Fax: 412-893-1844 + mailto:[EMAIL PROTECTED] -Original Message-From: Herd, Stewart [mailto:[EMAIL PROTECTED]Sent: Friday, March 21, 2003 11:23 AMTo: [EMAIL PROTECTED]Subject: Candle Command Centre and MQSeries First let me explain that in the MTSP QMGR we have MQ channels going out to: AAR_MTSP.AAR_AARP AAR_MTSP.AAR_MTST AAR_MTSP.CCRA_TITAN AAR_MTSP.CNR_MCP2 AAR_MTSP.CPR_MQP2 MTSP.TO.MQOHUXP1.BIN MTSP.USCS_MQB1 SGRC.MTSP.ZCC1 All except the top 2 are in remote networks. These are all SNA except for the Sun Solaris. I have the batch size set to 500 for the channels to the other in-house QMGRs as the volume is very high. The volume to MTST is not high, though. If you look inside the CCC task CANSCMSA at the DD RKLVLOG, you can see the activity. The issue is that the CCC is sending out false channel indoubt alerts, and I think they are always for the high activity channels between MTSP and AARP. Sometimes the indoubt period is perceived to be short, but here is one that is not: 09:48:09.14 KO41041 Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is true. 09:53:09.11 KO41042 Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is no longer true. From this message, you cannot know which channel it MTSP it was. These are showing up as red button alerts on the CCC monitor. When one of these long ones occurs, you can look at MQ with the MQ panel, and the channel is NOT in an indoubt status. I have turned off the channel events going to 'SYSTEM.ADMIN.CHANNEL.EVENT', which the CCC reads, but it is gather this info by observing the QMGR in a non-intrusive way. That's what Candle calls it. So, this is the issue. Operations is being bombarded with channel indoubt alerts, which in my opinion are not actually occurring. Has anyone had a similar experience or any ideas? Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland Office +353 21 2309331 Mobile +353 86 1713777
MQ Multithreading
Hi, We have a CICS (S390 <==> AIX) LU6.2 application that is multithreaded with up to 8 tranactions. This is being converted to MQ. Can you do multithreading with MQ ? If so, any ideas on how to go about it. TIA Dean Dean Montevago Sr. Software Specialist Visiting Nurse Service of N.Y. phone : (212) 290 - 0543 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
Re: Candle Command Centre and MQSeries
I defined a situation that traps the INDOUBT event and assigned it as a warning (yellow), so Operations basically ignores it. I suppose you could assign it as a "Not Monitored" situation via the MQSeries Manager template, or delete/stop the situation if you do not wish to get any alerts at all. BTW, I think you should change your background color (gray) to white. It's a little tough to read. "Herd, Stewart" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S-INC.COM> cc: Sent by: Subject: Candle Command Centre and MQSeries MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/21/2003 11:22 AM Please respond to MQSeries List First let me explain that in the MTSP QMGR we have MQ channels going out to: AAR_MTSP.AAR_AARP AAR_MTSP.AAR_MTST AAR_MTSP.CCRA_TITAN AAR_MTSP.CNR_MCP2 AAR_MTSP.CPR_MQP2 MTSP.TO.MQOHUXP1.BIN MTSP.USCS_MQB1 SGRC.MTSP.ZCC1 All except the top 2 are in remote networks. These are all SNA except for the Sun Solaris. I have the batch size set to 500 for the channels to the other in-house QMGRs as the volume is very high. The volume to MTST is not high, though. If you look inside the CCC task CANSCMSA at the DD RKLVLOG, you can see the activity. The issue is that the CCC is sending out false channel indoubt alerts, and I think they are always for the high activity channels between MTSP and AARP. Sometimes the indoubt period is perceived to be short, but here is one that is not: 09:48:09.14 KO41041Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is true. 09:53:09.11 KO41042Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is no longer true. From this message, you cannot know which channel it MTSP it was. These are showing up as red button alerts on the CCC monitor. When one of these long ones occurs, you can look at MQ with the MQ panel, and the channel is NOT in an indoubt status. I have turned off the channel events going to 'SYSTEM.ADMIN.CHANNEL.EVENT', which the CCC reads, but it is gather this info by observing the QMGR in a non-intrusive way. That's what Candle calls it. So, this is the issue. Operations is being bombarded with channel indoubt alerts, which in my opinion are not actually occurring. Has anyone had a similar experience or any ideas? Stewart Herd Senior Software Engineer Systems Engineering Services ACS NSC Campus Loughmahon Technology Park Cork Ireland Office +353 21 2309331 Mobile +353 86 1713777 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
Candle Command Centre and MQSeries
First let me explain that in the MTSP QMGR we have MQ channels going out to: AAR_MTSP.AAR_AARP AAR_MTSP.AAR_MTST AAR_MTSP.CCRA_TITAN AAR_MTSP.CNR_MCP2 AAR_MTSP.CPR_MQP2 MTSP.TO.MQOHUXP1.BIN MTSP.USCS_MQB1 SGRC.MTSP.ZCC1 All except the top 2 are in remote networks. These are all SNA except for the Sun Solaris. I have the batch size set to 500 for the channels to the other in-house QMGRs as the volume is very high. The volume to MTST is not high, though. If you look inside the CCC task CANSCMSA at the DD RKLVLOG, you can see the activity. The issue is that the CCC is sending out false channel indoubt alerts, and I think they are always for the high activity channels between MTSP and AARP. Sometimes the indoubt period is perceived to be short, but here is one that is not: 09:48:09.14 KO41041 Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is true. 09:53:09.11 KO41042 Enterprise situation MQSeries_Channels_Indoubt:MTSP:ASYS:MQESA is no longer true. From this message, you cannot know which channel it MTSP it was. These are showing up as red button alerts on the CCC monitor. When one of these long ones occurs, you can look at MQ with the MQ panel, and the channel is NOT in an indoubt status. I have turned off the channel events going to 'SYSTEM.ADMIN.CHANNEL.EVENT', which the CCC reads, but it is gather this info by observing the QMGR in a non-intrusive way. That's what Candle calls it. So, this is the issue. Operations is being bombarded with channel indoubt alerts, which in my opinion are not actually occurring. Has anyone had a similar experience or any ideas? 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: Anyone tried putting large messages with Paul Clarke's "Q" program?
>You seem to be passing in 'q' as an argument to the -f switch, does that mean you're trying to put the contents of the 'q' utility on as a MQ message? What is the -=999 parameter for? Kulbir, The '-=' parameter tells queue to accept truncated messages larger than this value, this is used when getting messages from a queue. For example q -IQ1 -=1 will remove messages from a queue and truncate every message after the first byte. This can be useful if you want to clear a queue, ie. q -IQ1 -=1 -q but don't want Q to have to allocate megabytes of storage just to read your large messages into. Note that whenever you are truncating messages you are effectively throwing away data though. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley --- 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
Belinda Edwards/Bethesda/IBM is out of the office.
I will be out of the office starting March 21, 2003 and will not return until March 24, 2003. 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: Anyone tried putting large messages with Paul Clarke's "Q" program?
You seem to be passing in 'q' as an argument to the -f switch, does that mean you're trying to put the contents of the 'q' utility on as a MQ message? What is the -=999 parameter for? "Nigel Phelan" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 21-Mar-2003 14:40 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Anyone tried putting large messages with Paul Clarke's "Q" program? Hi all - posted for a colleague in the hope someone knows the answer off the top of their head: "...Has anybody actually gotten q to send very large messages? If I try using various files it either splits it into lines or gets a Hconn error. % ./q -oBLAST -m minbar -=999 -f q MQSeries Q Program by Paul Clarke [ V4.1 Build:Oct 4 2002 ] Connecting ...connected to 'minbar '. MQPUT on object 'BLAST' returned 2018 Hconn error.. If I feed it a tar file it creates several thousand messages rather than one large one. Ideas?..." Nigel ---
Anyone tried putting large messages with Paul Clarke's "Q" program?
Hi all - posted for a colleague in the hope someone knows the answer off the top of their head: "...Has anybody actually gotten q to send very large messages? If I try using various files it either splits it into lines or gets a Hconn error. % ./q -oBLAST -m minbar -=999 -f q MQSeries Q Program by Paul Clarke [ V4.1 Build:Oct 4 2002 ] Connecting ...connected to 'minbar '. MQPUT on object 'BLAST' returned 2018 Hconn error.. If I feed it a tar file it creates several thousand messages rather than one large one. Ideas?..." Nigel ---
Re: MQSI 2.1 aggregate reply looping when error downstream
Hi Pierre, While reading your email the error looks familiar but when I saw the code everything looks fine. But when I took I closer look I saw in your code a really small detail which I think, could be the wrong thing. In your compute node you are building a wrong XML message. I noticed you wanted to add the XML declaration before your data. This is the correct ESQL code to add the xml declaration. --Create an XML Declaration SET OutputRoot.XML.(XML.XmlDecl)=''; --Set the Version within the XML Declaration SET OutputRoot.XML.(XML.XmlDecl).(XML.Version)='1.0'; --Set the Encoding within the XML Declaration SET OutputRoot.XML.(XML.XmlDecl).(XML."Encoding")='UTF-8'; --Set Standalone within the XML Declaration SET OutputRoot.XML.(XML.XmlDecl).(XML.Standalone)='no'; To complete your code you could take a look to section "Referencing information in XML message" in Chapter 2 in the ESQL reference manual. I hope this could help you. Cheers, Manuel Carlos Rodriguez IBM Certified Specialist - WebSphere MQ > -Mensaje original- > De: pierre La Fluffe [SMTP:[EMAIL PROTECTED] > Enviado el: Thursday, March 20, 2003 5:35 PM > Para: [EMAIL PROTECTED] > Asunto: MQSI 2.1 aggregate reply looping when error downstream > > Hi all > > I got a real bad problem, pulling my hair out, I can't work it out. > > I have an aggregate node and a downstream compute node. The compute node > complains as follows: > > ( MQSI_SAMPLE_BROKER.CCMS ) XML Writing Errors have occurred. > > Errors have occurred during writing of XML. > > Review further error messages for an indication to the cause of the > errors. > > XML looks fine see trace partial trace and the compute node code. The > problem then becoems wors that the aggregatereply mode goes into a loop a > reissueing errors - never stops (I run out of disk space). > > Firsttime in my trace I get a good ComIbmAggregateReplyBody record. > Subsequent times I get a null ComIbmAggregateReplyBody. > > The failing compute node is as follows: > > DECLARE I INTEGER; > SET I = 1; > WHILE I < CARDINALITY(InputRoot.*[]) DO > SET OutputRoot.*[I] = InputRoot.*[I]; > SET I=I+1; > END WHILE; > -- Enter SQL below this line. SQL above this line might be regenerated, > causing any modifications to be lost. > -- We assume it was the HostReply part that timed out, otherwise we have > big > problems. > > I have had this happen on Win2000 and HP-UX > > The input is somthing like: > --- > > > > > > > > --- > > > > Regards Pierre > ---COMPUTE NODE code-- > SET OutputRoot.MQMD.Version = 2; > SET OutputRoot.MQMD.Format = 'MQSTR '; > > --This is where it fails I assume > SET OutputRoot.XML."XML" = > InputRoot.ComIbmAggregateReplyBody.NextHost.XML.XML; > SET OutputRoot.XML."IFX" = > InputRoot.ComIbmAggregateReplyBody.NextHost.XML.IFX; > > SET OutputRoot.XML.MultiHost = > InputRoot.ComIbmAggregateReplyBody.NextHost.XML.MultiHost; > > This code has worked, and now it doesn't work - the input message has not > changed. > -- > > The trace is as follows: > > Root: > ( > (0x100)Properties = ( > (0x300)MessageSet = NULL > (0x300)MessageType = NULL > (0x300)MessageFormat = NULL > (0x300)Encoding= NULL > (0x300)CodedCharSetId = NULL > (0x300)Transactional = UNKNOWN > (0x300)Persistence = UNKNOWN > (0x300)CreationTime= NULL > (0x300)ExpirationTime = NULL > (0x300)Priority= NULL > (0x300)ReplyIdentifier = NULL > (0x300)ReplyProtocol = NULL > (0x300)Topic = NULL > ) > (0x100)ComIbmAggregateReplyBody = ( > (0x100)NextHost = ( > (0x100)Properties = ( > (0x300)MessageSet = '' > (0x300)MessageType = '' > (0x300)MessageFormat = 'XML' > (0x300)Encoding= 546 > (0x300)CodedCharSetId = 437 > (0x300)Transactional = FALSE > (0x300)Persistence = FALSE > (0x300)CreationTime= NULL > (0x300)ExpirationTime = -1 > (0x300)Priority= 0 > (0x300)ReplyIdentifier = > X'414d51204d5153495f53414d504c455fceb2793e12300200' > (0x300)ReplyProtocol = NULL > (0x300)Topic = NULL > ) > (0x100)MQMD = ( > (0x300)SourceQueue = '' > (0x300)Transactional= FALSE > (0x300)Encoding = 546 > (0x300)CodedCharSetId = 437 > (0x300)Format = 'MQSTR ' > (0x300)Version = 2 > (0x300)Report = 0 > (0x300)MsgType = 1 > (0x300)Expiry = -1 >
Re: A question on MQ and J2EE
Thanks to everybody who responded. I'm leaning toward option C, hence this additional question. > From: Rodrigo Vargas > Sent: Thursday, March 20, 2003 19:57 > Subject: Re: A question on MQ and J2EE > > Since you are using EJBs, you should be running on a J2EE server, consider > using a Message Driven Bean EJB (MDB), the J2EE container will manage the > thread pool for you. You will code the onMessage() method to do the > processing and put the message on the second queue. Ok, and how do I tell my MDB that the onMessage() method should wait for a message on a given MQ queue? In other words, where do you specify what kind of source (socket, MQ queue, whatever) do you want to poll for incoming data? Is this using JMS? If yes, does this support MQ "out-of-the-box"? Finally, and stretching my luck a bit, could you provide a pointer to a source code example? After all, I'm sure this has to be a very common use case. > Rodrigo Thanks, -- Gonzalo A. Diethelm [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
AW: Backup CFstruct
Hello, here is a sample what you could do using netview or any other proper automation tool: do every hour if qmgr a available issue dis cfstruct(*) on qma else if qmgr b available issue dis cfstruct(*) on qmb endif issue backup cfstruct for every structure on proper qma/b end do anyway, it depends on your amount of data and the way the application works. messages should not reside in queues for hours , especially if these queues are shared queues. it also depends on how busy your queuemanager is and how many logdata has to be read in case of a recovery situation. anyway, try keep backups small (try to keep queues empty) and try to do frequent backups to minimize recovery time (especially for production systems) maybe it makes sense to do backups depending on queuemanager (or beter, qsg) activity, e.g. depending on the number of active log switches. just an idea, i did not think much about it yet. regards stefan -Ursprüngliche Nachricht- Von: Dijkerman, E (Erik) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 21. März 2003 10:44 An: [EMAIL PROTECTED] Betreff: Backup CFstruct Listeners, Did one of you already setup a Backup strategy for your structures and wants to share this?? Regards, Erik Dijkerman X Rabobank ICT/Serverbedrijf PIM/OS390 ZL-S206400 Mailbox 17100, 3500 HG Utrecht *(030) 215 4878 *(030) 215 3085 ? [EMAIL PROTECTED] "The greatest amount of wasted time is the time not getting started." - Dawson Trotman De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. 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: Shared Data Tables vs. Coupling Facility
Hmmm, as an ex-CICS SysProg I should know this but it's been a while. There is a CICS list where you might get the answer. Register at [EMAIL PROTECTED] mqm --- regissr <[EMAIL PROTECTED]> wrote: > Hi everybody, > > Please i have the following doubt : > > I'd like to know if "CICS Shared Data Tables" use > Coupling > Facility ? Are this subject completely different ? > > I was studying "CICS Shared Data Tables Guide" , > and i saw > at chapter 1.8.2 Using Shared Data Tables services > at Figure > 2 Data access using shared data table services. This > diagram > shows read-only access only. > > In this figure , there is a term called DATA > SPACE. > Please , can anyone explain me concepts about this ? > What's DATA SPACE limit ? > > Thanks in advance > > Reginaldo S. Rosa > > > > > > > > > --- > UOL, o melhor da Internet > http://www.uol.com.br/ > > 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 __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.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 Control-m job
Can you explain in a bit more detail what you mean by "triggering a Control-m job". Isn't Control-M the BMC scheduler? In which case you will be scheduling the batch jobs rather than triggering them. What platform are you on? mqm --- Burke Edward <[EMAIL PROTECTED]> wrote: > > Has anyone had any experience with triggering > Control-m batch jobs from > Mqseries ? > > If so how did you go about it ? > > > > __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.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
Backup CFstruct
Listeners, Did one of you already setup a Backup strategy for your structures and wants to share this?? Regards, Erik Dijkerman X Rabobank ICT/Serverbedrijf PIM/OS390 ZL-S206400 Mailbox 17100, 3500 HG Utrecht *(030) 215 4878 *(030) 215 3085 ? [EMAIL PROTECTED] "The greatest amount of wasted time is the time not getting started." - Dawson Trotman De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. 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
