Re: MQSeries 5.3 on XP
Title: RE: MQSeries 5.3 on XP Hi, I recently also tried this. According to the CSD you should run the command "x:\setup.exe AMQ_XP_INSTALL_PENDING_CSD=1" from DOS-ptompt to install, but this still did not work. I found a note in the archives which solved the problem - you should run the command "mqparms.exe AMQ_XP_INSTALL_PENDING_CSD=1" - I tried it and it worked. Andre -Original Message- From: "Rodríguez Alvarez-Querol, Manuel Carlos" [mailto:[EMAIL PROTECTED]] Sent: 05 February 2004 03:58 To: [EMAIL PROTECTED] Subject: Re: MQSeries 5.3 on XP Hi, WebSphere MQ 5.3 GA does not support XP. Then, to install it, just install mq with the following command line and install the latest csd. x:\setup.exe AMQ_XP_INSTALL_PENDING_CSD=1 You could also take a look to http://www-1.ibm.com/support/docview.wss?uid=swg27004410&aid=1 which is the latest CSD readme file. > -Mensaje original- > De: Kerry Swemmer [SMTP:[EMAIL PROTECTED] > Enviado el: Thursday, 05 February, 2004 2:45 PM > Para: [EMAIL PROTECTED] > Asunto: MQSeries 5.3 on XP > > Hi All, > > I am trying to install 5.3 on Windows XP and am getting the following > > AMQ4755 This version of IBM WebSphere MQ > does not yet support Windows XP. A > CSD will provide this support. > > Any ideas? I cannot find any related CSD. > > Thanx, > Kerry. > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of John > Scott > Sent: 18 November 2003 10:49 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > You still get an improvement by using syncpoint after every message. The > test I did reduced the time for 1000 persistent messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED]] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your CPU > > speed etc etc. > > > > There are also, I believe, a number of support pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | N.AC.AT> | > > | | | > > | | | > > | | 17/11/2003 16:59 | > > | | Please respond to| > > | | MQSeries List | > > |-+> > > > > > >- > -- > | > > | > > > > | > > | To: [EMAIL PROTECTED] > > > > | > > | cc: > > > > | > > | Subject: Impact of Syncpoint? > > > > | > > | > > > > | > > | > > > > | > > > > > >- > -- > --
Sorry about this one!!!
http://www.wired.com/wired/archive/12.02/india.html _ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx 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
FW: List of Queue Managers in Cluster - How to get via "C" code
I', posting this again in case people missed with the myDoom mail overload. Any help would be great. Sid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 February 2004 11:56 AM To: [EMAIL PROTECTED] Subject: List of Queue Managers in Cluster - How to get via "C" code Howdy all, What is the best way to get a list of all the queue managers that are in a cluster using "C" code. Does anyone have a sample of code they could share ? Sid Young Brisbane 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: Client Channel Table definition
I have to ask how are you trying to use the 2nd and 3rd entries? Have u spec'd QMNAME on the channel def and then spec'd the same name on the amqsputc? Wayne M. Schutz, IBM. -Original Message- From: Nushi M. [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Re: Client Channel Table definition Hello All, I got the table to connect to mainframe from NT using sample program AMQSPUTC. The problem I have now is that only works with the first entry in the table. I am not able to connect to the second queue manager IP address and port in the table. Any clues ?. 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: Client Channel Table definition
Hi, can you post the CLNTCONN definitions which you are extracting to build the client table, and also the exact commands you are using (the one which works and the ones which are failing). Client connections can go wrong in several ways, and without seeing what you are doing, it is hard to guess what the problem might be. Feel free to blank out the IP addesses/host names from the definitions. Regards, Neil C. |-+> | | "Nushi M." | | | <[EMAIL PROTECTED]| | | COM> | | | Sent by: MQSeries| | | List | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 06/02/2004 09:15 | | | Please respond to| | | MQSeries List| | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: Client Channel Table definition | >--| Good advise, But there is no MQSERVER variable in my PC. I am able to connect to any queue manager as long as it is the first defined in the table not second or third. "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> wrote: Neil, this may be a silly question, but are you sure you don't have MQSERVER set to the values for the first entry? -Original Message- From: Nushi M. [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 12:24 PM To: [EMAIL PROTECTED] Subject: Re: Client Channel Table definition Hello All, I got the table to connect to mainframe from NT using sample program AMQSPUTC. The problem I have now is that only works with the first entry in the table. I am not able to connect to the second queue manager IP address and port in the table. Any clues ?. Neil Casey <[EMAIL PROTECTED]> wrote: Hello, your description of creating the channel table looks Ok I think, although the manual for WMQ5.3 has an example which includes a CCSID and Authinfo: COMMAND DDNAME (CMDCHL) MAKECLNT(OUTCLNT) CCSID(437) DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN) DISPLAY AUTHINFO (*) ALL The authinfo should only be needed if you are using SSL (I think). MQ5.3 has also changed the dataset definition to RECFM=U, LRECL=6144, BLKSIZE=2048, although I must say that these values look a bit strange. You don't say whether your client connection works when you do it via an MQSERVER variable. If you haven't got it working using MQSERVER, get it going that way first, and then change to the client channel table so that you know that the mainframe configuration is correct before you begin testing. It also verifies TCP/IP comms etc, so if your channel table doesn't work and your MQSERVER does, you know where the problem has to be. If you have already done this (ie you know that it works with MQSERVER and not with a channel table) then I would look to compare the content of the CLNTCONN definition with the MQSERVER values. Lastly, (and I apologise if this is totally obvious) the client connection feature is an extra cost option on WMQ for zOS, so you need to ensure that it is installed. Regards, Neil C. |-+> | | "Nushi M." | | | | | COM> | | | Sent by: MQSeries| | | List | | | | | n.AC.AT> | | | | | | | | | 05/02/2004 09:05 | | | Please respond to| | | MQSeries List | | | | |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Client Channel Table definition | >--| Hello al
Re: Client Channel Table definition
Good advise, But there is no MQSERVER variable in my PC. I am able to connect to any queue manager as long as it is the first defined in the table not second or third. "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> wrote: Neil, this may be a silly question, but are you sure you don't have MQSERVER set to the values for the first entry? -Original Message-From: Nushi M. [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 12:24 PMTo: [EMAIL PROTECTED]Subject: Re: Client Channel Table definition Hello All, I got the table to connect to mainframe from NT using sample program AMQSPUTC. The problem I have now is that only works with the first entry in the table. I am not able to connect to the second queue manager IP address and port in the table. Any clues ?. Neil Casey <[EMAIL PROTECTED]> wrote: Hello,your description of creating the channel table looks Ok I think, althoughthe manual for WMQ5.3 has an example which includes a CCSID and Authinfo:COMMAND DDNAME (CMDCHL) MAKECLNT(OUTCLNT) CCSID(437)DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)DISPLAY AUTHINFO (*) ALLThe authinfo should only be needed if you are using SSL (I think).MQ5.3 has also changed the dataset definition to RECFM=U, LRECL=6144,BLKSIZE=2048, although I must say that these values look a bit strange.You don't say whether your client connection works when you do it via anMQSERVER variable.If you haven't got it working using MQSERVER, get it going that way first,and then change to the client channel table so that you know that themainframe configuration is correct before you begin testing. It alsoverifies TCP/IP comms etc, so if your channel table doesn't work and yourMQSERVER does, you know where the problem has to be. If you have alreadydone this (ie you know that it works with MQSERVER and not with a channeltable) then I would look to compare the content of the CLNTCONN definitionwith the MQSERVER values.Lastly, (and I apologise if this is totally obvious) the client connectionfeature is an extra cost option on WMQ for zOS, so you need to ensure thatit is installed.Regards,Neil C.|-+>| | "Nushi M." || | <[EMAIL PROTECTED]|| | COM> || | Sent by: MQSeries|| | List || | <[EMAIL PROTECTED]|| | n.AC.AT> || | || | || | 05/02/2004 09:05 || | Please respond to|| | MQSeries List || | ||-+>>--|| || To: [EMAIL PROTECTED] || cc: || Subject: Client Channel Table definition |>--|Hello all:= "urn:schemas-microsoft-com:office:office" />I have problems connecting to mainframe from WIN 2000 using MQCHLTAB.I would be appreciated if you can help me resolve this issue.I have followed the direction of creating this table according to theClient book chapter 8, 9, and the Intercommunication.When I run the sample program "amqsputc" I get error code 2058 (MQCONN).This tell me that there is a problem with my channel table definitions:Here are the steps I am taking to do this process.1. I created the MQCHLTAB file using MAKECLNT for CLNTCONN as followsThis file attributes is blksize=2048, lrecl=2048, RECFM=U""//MAKECL EXEC PGM=CSQUTIL,REGION=4096K,// PARM='MQI2'//STEPLIB DD DSN=SYS91.MQ.SCSQANLE,DISP=SHR// DD DSN=SYS91.MQ.SCSQAUTH,DISP=SHR//OUTCLNT DD DISP=MOD,DSN=MQ.CL.TAB1//SYSPRINT DD SYSOUT=*//SYSIN DD *COMMAND DDNAME(CMDCHL) MAKECLNT(OUTCLNT)/*//CMDCHL DD *DISPLAY CHANNEL(WAS.SVR) ALL TYPE(CLNTCONN)2. I ftp the file to WIN 2000 using Binary option.I read the file using notepad and I can see the channel definitionsand at the end has garbage as well.3. I set the Environment variable in my PC as follows:SET MQCHLLIB = MQCHLTAB.TAB which is the name of my binary file thatI FTP from mainframe.4. I setup Environment variable also for the path asMQCHLLIB = C:\mqm\This is the path for the MQCHLTAB.TAB.THANK YOU FOR YOUR HELP.Do you Yahoo!?Yahoo! SiteBuilder - Free web site building tool. Try it!Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive Do you Yahoo!?Yahoo! Finance: Get your refund fast by filing online ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
Re: link listed libraries
http://publibfp.boulder.ibm.com/epubs/pdf/igy3pg00.pdf CALL PROGRAM Making static calls When you use the CALL literal statement in a program that is compiled using the NODYNAM and NODLL compiler options, a static call occurs. CALL 'program' Making dynamic calls When you use the CALL literal statement in a program that is compiled using the DYNAM and the NODLL compiler options, or when you use the CALL identifier statement in a program that is compiled using the NODLL compiler option, a dynamic call occurs. The program name in the PROGRAM-ID paragraph or ENTRY statement must be identical to the corresponding load module name or load module alias of the load module that contains it. In this form of the CALL statement, the called COBOL subprogram is not link-edited with the main program, but is instead link-edited into a separate load module, and is loaded at run time only when it is required (that is, when called). "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: link listed libraries Sent by: MQSeries List <[EMAIL PROTECTED] N.AC.AT> 02/05/2004 01:26 PM Please respond to MQSeries List Dave, I'm not a Cobol person, so I'm not sure off the top of my head. That's one of those things I always have to look up when a programmer stops by with a problem/question. -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 4:01 PM To: [EMAIL PROTECTED] Subject: Re: link listed libraries Rebecca now I am wondering if CALL 'program'is static and CALL PROGRAM is dynamic Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject:Re: link listed libraries 02/05/2004 01:32 PM Please respond to MQSeries List Dave, did you remember to refresh LLA? -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: link listed libraries to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibit
Re: link listed libraries
CALL data-name is dynamic. CALL 'PROGRAM' is dynamic if compiled with the DYNAM compiler option. CALL 'PROGRAM' is static if compiled with the NODYNAM compiler option. Dave Adam <[EMAIL PROTECTED]To: [EMAIL PROTECTED] RVALU.COM> cc: Sent by: MQSeriesSubject: Re: link listed libraries List <[EMAIL PROTECTED] n.ac.at> 02/05/2004 03:00 PM Please respond to MQSeries List Rebecca now I am wondering if CALL 'program'is static and CALL PROGRAM is dynamic Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> To: Sent by: MQSeries List [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Subject:Re: link listed libraries 02/05/2004 01:32 PM Please respond to MQSeries List Dave, did you remember to refresh LLA? -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: link listed libraries to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. 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: link listed libraries
On Thu, 5 Feb 2004 15:00:37 -0600 Dave Adam <[EMAIL PROTECTED]> wrote: :>now I am wondering if :>CALL 'program'is static Depends on your compiler options. :>and :>CALL PROGRAM is dynamic Yes. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel 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: link listed libraries
Dave, I'm not a Cobol person, so I'm not sure off the top of my head. That's one of those things I always have to look up when a programmer stops by with a problem/question. -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 4:01 PMTo: [EMAIL PROTECTED]Subject: Re: link listed librariesRebecca now I am wondering if CALL 'program' is static and CALL PROGRAM is dynamicDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 02/05/2004 01:32 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: link listed librariesDave, did you remember to refresh LLA? -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 1:52 PMTo: [EMAIL PROTECTED]Subject: link listed librariesto get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed librariesDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: link listed libraries
Dave, evidently something somewhere has something cached. Could it be VLF? But you did say that this was an additional module, didn't you? So, I guess not. Just to verify:It IS the same library on the same volser? (That is grasping at straws) Do you have any software that does LLA monitoring? Maybe something's getting in the way. (How about if you build the routine from LPAR A, too? Might not be elegant, but "it might work" trumps elegant every time). Oh -- an idea: Could the lnklst dataset have gone into another extent AFTER A was last IPLed but before B was? What I'm thinking here is that the new routine went into a second extent that B knows about but A doesn't. Just a thought. -- Rebecca P.S. I know this is somewhat incoherent; it's more stream-of-consciousness as things occurred to me. -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 3:39 PMTo: [EMAIL PROTECTED]Subject: Re: link listed librarieshere's a twist (SYSPlex of course) the systems programmer was logged on to LPAR "B" when he built the routine he did a LLA refresh on all LPAR's in the sysplex I got on to LPAR "A" and my code was consistent, but did not work from the link listed library put in a SYSAFF to LPAR "B" and it works he put in a SYSAFF to LPAR "A" and his doesn't work (even after another LLA refresh) now we are really stumpedDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 02/05/2004 01:32 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: link listed librariesDave, did you remember to refresh LLA? -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 1:52 PMTo: [EMAIL PROTECTED]Subject: link listed librariesto get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed librariesDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: SSL - OS400 and OS390
When do you want the message encrypted whilst it is in transit or when its sitting around on a queue or both? Personally SSL for an internal LAN is overkill but it depends on how high a value the messages are and whether there are SVRCONN channels available. Regards Tim Armstrong -Original Message- From: Pat O'Dowd [mailto:[EMAIL PROTECTED] Sent: Friday, 6 February 2004 5:03 AM To: [EMAIL PROTECTED] Subject: SSL - OS400 and OS390 Before acting on this e-mail or opening any attachment, you are advised to read the disclaimer at the end of this mail. Hi, I am looking to use SSL on the channels between an OS400 and an OS390 machine. Both machines are on MQ 5.3. All the traffic on the channels is within a LAN. The messages are high value. For a production environment, would it be recommended to get the certificates from an external certification Authority or could something like Digital Certificate Manager (DCM) on OS400 be used to manage/generate the certificates for both machines? >From what I see of SSL on NT, it seems fairly straightforward to configure. Has anyone used it to connect OS400 and OS390? How painful was it? What kind of problems/issues did you encounter? Would the use of SSL be considered overkill in an environment like this? Thanks in advance. ** This e-mail is intended solely for the addressee and is strictly confidential. If you are not the addressee, please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead please e-mail it back to the sender and delete the message from your computer. E-mail transmission cannot be guaranteed to be secure or error free and The Co-operative Bank accepts no liability for changes made to this e-mail (and any attachments) after it was sent or for viruses arising as a result of this e-mail transmission. Any unauthorised reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited. The Co-operative Bank reserves the right to intercept any e - mails or other communication for permitted purposes in accordance with the current legislation which you send to, or receive from, any of the employees or agents of the Bank via Bank telecommunication systems. By so corresponding you also give your consent to the Bank monitoring and recording of any correspondence using these systems. The Co-operative Bank p.l.c. is registered in England and Wales, number 990937. The registered office is at PO Box 101, 1, Balloon Street, Manchester, M60 4EP. ** Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.
Re: link listed libraries
Rebecca now I am wondering if CALL 'program' is static and CALL PROGRAM is dynamic Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 02/05/2004 01:32 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: link listed libraries Dave, did you remember to refresh LLA? -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: link listed libraries to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: link listed libraries
here's a twist (SYSPlex of course) the systems programmer was logged on to LPAR "B" when he built the routine he did a LLA refresh on all LPAR's in the sysplex I got on to LPAR "A" and my code was consistent, but did not work from the link listed library put in a SYSAFF to LPAR "B" and it works he put in a SYSAFF to LPAR "A" and his doesn't work (even after another LLA refresh) now we are really stumped Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 02/05/2004 01:32 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: link listed libraries Dave, did you remember to refresh LLA? -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: link listed libraries to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic -- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
SSL - OS400 and OS390
Before acting on this e-mail or opening any attachment, you are advised to read the disclaimer at the end of this mail. Hi, I am looking to use SSL on the channels between an OS400 and an OS390 machine. Both machines are on MQ 5.3. All the traffic on the channels is within a LAN. The messages are high value. For a production environment, would it be recommended to get the certificates from an external certification Authority or could something like Digital Certificate Manager (DCM) on OS400 be used to manage/generate the certificates for both machines? >From what I see of SSL on NT, it seems fairly straightforward to configure. Has anyone used it to connect OS400 and OS390? How painful was it? What kind of problems/issues did you encounter? Would the use of SSL be considered overkill in an environment like this? Thanks in advance. ** This e-mail is intended solely for the addressee and is strictly confidential. If you are not the addressee, please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead please e-mail it back to the sender and delete the message from your computer. E-mail transmission cannot be guaranteed to be secure or error free and The Co-operative Bank accepts no liability for changes made to this e-mail (and any attachments) after it was sent or for viruses arising as a result of this e-mail transmission. Any unauthorised reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message is strictly prohibited. The Co-operative Bank reserves the right to intercept any e - mails or other communication for permitted purposes in accordance with the current legislation which you send to, or receive from, any of the employees or agents of the Bank via Bank telecommunication systems. By so corresponding you also give your consent to the Bank monitoring and recording of any correspondence using these systems. The Co-operative Bank p.l.c. is registered in England and Wales, number 990937. The registered office is at PO Box 101, 1, Balloon Street, Manchester, M60 4EP. ** 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
Anyone running MQ 5.3 on Windows 2003 Enterprise Edition?
Hi, We have a requirement to move our existing Websphere MQ installations from W2K to Windows 2003 Enterprise edition. I see on the IBM web site that it is supported (with a few installation caveats in the Readme file), but I was wondering if anyone out there is running WMQ 5.3 on this version of Windows. Any issues? Thanks, Lynn
Re: link listed libraries
Dave, did you remember to refresh LLA? -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 1:52 PMTo: [EMAIL PROTECTED]Subject: link listed librariesto get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed librariesDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A lone amateur built the Ark. A large group of professionals built the Titanic-- ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: Client Channel Table definition
Neil, this may be a silly question, but are you sure you don't have MQSERVER set to the values for the first entry? -Original Message-From: Nushi M. [mailto:[EMAIL PROTECTED]Sent: Thursday, February 05, 2004 12:24 PMTo: [EMAIL PROTECTED]Subject: Re: Client Channel Table definition Hello All, I got the table to connect to mainframe from NT using sample program AMQSPUTC. The problem I have now is that only works with the first entry in the table. I am not able to connect to the second queue manager IP address and port in the table. Any clues ?. Neil Casey <[EMAIL PROTECTED]> wrote: Hello,your description of creating the channel table looks Ok I think, althoughthe manual for WMQ5.3 has an example which includes a CCSID and Authinfo:COMMAND DDNAME (CMDCHL) MAKECLNT(OUTCLNT) CCSID(437)DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)DISPLAY AUTHINFO (*) ALLThe authinfo should only be needed if you are using SSL (I think).MQ5.3 has also changed the dataset definition to RECFM=U, LRECL=6144,BLKSIZE=2048, although I must say that these values look a bit strange.You don't say whether your client connection works when you do it via anMQSERVER variable.If you haven't got it working using MQSERVER, get it going that way first,and then change to the client channel table so that you know that themainframe configuration is correct before you begin testing. It alsoverifies TCP/IP comms etc, so if your channel table doesn't work and yourMQSERVER does, you know where the problem has to be. If you have alreadydone this (ie you know that it works with MQSERVER and not with a channeltable) then I would look to compare the content of the CLNTCONN definitionwith the MQSERVER values.Lastly, (and I apologise if this is totally obvious) the client connectionfeature is an extra cost option on WMQ for zOS, so you need to ensure thatit is installed.Regards,Neil C.|-+>| | "Nushi M." || | <[EMAIL PROTECTED]|| | COM> || | Sent by: MQSeries|| | List || | <[EMAIL PROTECTED]|| | n.AC.AT> || | || | || | 05/02/2004 09:05 || | Please respond to|| | MQSeries List || | ||-+>>--|| || To: [EMAIL PROTECTED] || cc: || Subject: Client Channel Table definition |>--|Hello all:= "urn:schemas-microsoft-com:office:office" />I have problems connecting to mainframe from WIN 2000 using MQCHLTAB.I would be appreciated if you can help me resolve this issue.I have followed the direction of creating this table according to theClient book chapter 8, 9, and the Intercommunication.When I run the sample program "amqsputc" I get error code 2058 (MQCONN).This tell me that there is a problem with my channel table definitions:Here are the steps I am taking to do this process.1. I created the MQCHLTAB file using MAKECLNT for CLNTCONN as followsThis file attributes is blksize=2048, lrecl=2048, RECFM=U""//MAKECL EXEC PGM=CSQUTIL,REGION=4096K,// PARM='MQI2'//STEPLIB DD DSN=SYS91.MQ.SCSQANLE,DISP=SHR// DD DSN=SYS91.MQ.SCSQAUTH,DISP=SHR//OUTCLNT DD DISP=MOD,DSN=MQ.CL.TAB1//SYSPRINT DD SYSOUT=*//SYSIN DD *COMMAND DDNAME(CMDCHL) MAKECLNT(OUTCLNT)/*//CMDCHL DD *DISPLAY CHANNEL(WAS.SVR) ALL TYPE(CLNTCONN)2. I ftp the file to WIN 2000 using Binary option.I read the file using notepad and I can see the channel definitionsand at the end has garbage as well.3. I set the Environment variable in my PC as follows:SET MQCHLLIB = MQCHLTAB.TAB which is the name of my binary file thatI FTP from mainframe.4. I setup Environment variable also for the path asMQCHLLIB = C:\mqm\This is the path for the MQCHLTAB.TAB.THANK YOU FOR YOUR HELP.Do you Yahoo!?Yahoo! SiteBuilder - Free web site building tool. Try it!Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive Do you Yahoo!?Yahoo! Finance: Get your refund fast by filing online ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for yo
link listed libraries
to get the QMGR name out of the SYSPlex we put a routine in SYS1.PP.LINKLIB made it a dynamic call in the program but can't seem to get it to work (when I do get it to work, the MQCONN call does not work) now if I concatenate SYS1.PP.LINKLIB in the STEPLIB, all works fine has anyone experienced problems with dynamic calls to programs from link listed libraries Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] A lone amateur built the Ark. A large group of professionals built the Titanic --
Customized authentication Scheme
Hi all, Sorry for the long email, but we have a requirement here that we are trying to meet and looks like MQ Series is not designed to do what we are trying to achieve. We have a requirement where we need to send and retrieve messages from a client machine to a server machine using an authentication scheme, which verifies authenticating a user id, and password as well as a secondary password (security token) and version number against entries in a database. User credentials being used in this authentication process are different from the credentials of the user logged on to that machine, so the authentication scheme cannot be tied into the authentication provided by the operating system (using Windows). So i turned the authentication service on the Queue Manager and we are using our own authentication algorithm. Currently i am trying to do this using security exits in a MQ Series (5.3) client/server environment. Although i have problems: - sending information from the calling application to the client security dll - also sending the result of authentication back from the security exits to the calling application. I did find work around for both the cases: - tried using MQCD struct to send info from calling application to the client side security exit. Different story i had to hack MQCD.Desc & MQD.XmitQueue for different purposes, which i am sure is an advisable thing to do.. - resolved the second problem by having the client side security exit write the return code to a file (the file name is a GUID created by the calling application and is sent to the client security exit in MQCD.Desc variable when the client security exit is triggered) client machine (where the calling application also resides). This is the most hopeless work around i ever came up with... and i am highly uncomfortable keeping it as a solution. Any information is appreciated.. And the story does not end here, Even with the work around in place, in a scenario where more than one clients try to access the Queue Manager at the same time, the server side security exit behaves differently. In other words say the first client issues an MQCONNX call and during this period where the exits are busy authenticating the user the second client issues an MQCONNX and this call also triggers the same server side security exit. Now in this case sometimes, both the clients finish their MQCONNX call successfully or one of them does and the other fails with 2059 and an channel ended by exit error forced to the STDERR. Now this is the simplest scenario, usually our architecture should support a common scenario of 100 users hitting the same queue manager at the same time. Does MQ support what i am trying to achieve here ? Am i doing something wrong ? Do you guys think that using MQ EveryPlace instead of MQ client would help any, as far as authentication/security scheme goes ? Thanks Usha 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: Question to MQForum ADMINISTRATORS
Another way to handle this was "explained" to me by an administrator on a very slow listserv (ie: few messages) who unsubscribes people who send "out of office" auto-replies to his list. Well behaving auto-replies only send one reply per sender. This is controlled by a "reply" file that tracks replies as they are made. When you turn on your "out of office" reply, it starts writing to this file (creates it the first time if it doesn't exist). When you turn off your "out of office" reply, it deletes this file. If you keep a copy of this file with addresses you don't want to send any replies to (for me this entry looks like IN%"[EMAIL PROTECTED]" for this list) then you can avoid being an annoyance. I try to remember to do this and hopefully it actually works. I'm hoping it does since I haven't been unsubscribed since... By the way, I have some "un-magic days" coming up the week of Feb 16. Hopefully I'll remember this bit of netiquette. Kip Bryant |Rao, |The list administrators do not monitor the list and you should send your |request to them directly. If you do not already know how to obtain the |administrator addresses from the list server, digging that info out of the |docs is a really good introduction in the L-Soft list server command |language. You'd be surprised at all the things you can do by sending |commands to the list server! Obtaining the list admin addresses is just the |tip of the iceberg. The link to the list server docs is at the bottom of |every email from the list. |That being said, most list admins will not respond to a request of this |nature from an individual user. The list community would need to form a |consensus that filtering of emails is a Good Thing. Upon receipt of a |request such as yours, the first thing a List Admin will usually ask is |whether the requestor represents the community at large or is merely |expressing their own personal preference. Without support of the majority |of the list community, such requests are routinely refused. |In general, list admins are loathe to filter anything at all, on the |principle that it is better to allow some noise than to inadvertently filter |some signal. Even with the out-of-office responses, this list has a |consistently high signal-to-noise ratio compared to most other unmoderated |lists. However if this really, *really*, REALLY bugs you, it would be |appropriate to post a thread to the group, not the administrators, asking |for the opinion of the other members of this community. If you are |persuasive and people on the list generally agree, then a request to the |list admins would carry a lot more weight. |Incidentally, one of the commands that you can send to the list server will |suspend incoming messages while you are out of the office. The command is |"SET MQSERIES NOMAIL", if I remember correctly. Now, I know you said you |did not want suggestions "such as putting filters at the recipient end" and |this is not one of those, I promise, but bear with me. What would be really |cool is if you could set up your own auto-reply that would see the incoming |Out Of Office messages and send that person, offlist, instructions for |turning off their subscription while they are away. This has two benefits - |first, obviously, some of those people would remember to turn off their |subscriptions on their next holiday thus reducing the number of Out Of |Office replies you get; second, you would gradually build up a database of |subject lines on which to filter. Then when you do send a request to the |list administrators, you can include all the filtering rules that they |should set up. |Finally, you should realize that almost all of the Out-Of-Office replies you |get ARE *NOT* FROM THE LIST SERVER!!! They are sent directly to you because |the auto-responders use the "from" address and not the "reply-to" address |when they create an Out-Of-Office reply. So anything the list admins might |do for you would stop - at most - the two or three out-of-office replies a |month that actually pass through the list server. I thought you'd rather |find this out now than to go through all the work of getting the list |configuration changed only to discover it wouldn't make a dent in the number |of Out-Of-Office replies that you get. |Since you do not want to use a filter on the recipient end, and since the |offending emails are sent directly to you and cannot be filtered out any |other way, there are very few options for reducing these annoying emails. |In fact, the only one I could think of was to simply not send any emails to |the list while people are out of the office or on holiday. To that end, I |like Chris Fryett's suggestion of obtaining everyone's out-of-office |schedule ahead of time. Even with 1500 people on the list, there are bound |to be some Magic Days when we are all here. By saving up all of one's list |postings for the Magic Days, one can safely send emails to the list without |getting Out-Of-Office re
Re: Client Channel Table definition
Hello All, I got the table to connect to mainframe from NT using sample program AMQSPUTC. The problem I have now is that only works with the first entry in the table. I am not able to connect to the second queue manager IP address and port in the table. Any clues ?. Neil Casey <[EMAIL PROTECTED]> wrote: Hello,your description of creating the channel table looks Ok I think, althoughthe manual for WMQ5.3 has an example which includes a CCSID and Authinfo:COMMAND DDNAME (CMDCHL) MAKECLNT(OUTCLNT) CCSID(437)DISPLAY CHANNEL(*) ALL TYPE(CLNTCONN)DISPLAY AUTHINFO (*) ALLThe authinfo should only be needed if you are using SSL (I think).MQ5.3 has also changed the dataset definition to RECFM=U, LRECL=6144,BLKSIZE=2048, although I must say that these values look a bit strange.You don't say whether your client connection works when you do it via anMQSERVER variable.If you haven't got it working using MQSERVER, get it going that way first,and then change to the client channel table so that you know that themainframe configuration is correct before you begin testing. It alsoverifies TCP/IP comms etc, so if your channel table doesn't work and yourMQSERVER does, you know where the problem has to be. If you have alreadydone this (ie you know that it works with MQSERVER and not with a channeltable) then I would look to compare the content of the CLNTCONN definitionwith the MQSERVER values.Lastly, (and I apologise if this is totally obvious) the client connectionfeature is an extra cost option on WMQ for zOS, so you need to ensure thatit is installed.Regards,Neil C.|-+>| | "Nushi M." || | <[EMAIL PROTECTED]|| | COM> || | Sent by: MQSeries|| | List || | <[EMAIL PROTECTED]|| | n.AC.AT> || | || | || | 05/02/2004 09:05 || | Please respond to|| | MQSeries List || | ||-+>>--|| || To: [EMAIL PROTECTED] || cc: || Subject: Client Channel Table definition |>--|Hello all:= "urn:schemas-microsoft-com:office:office" />I have problems connecting to mainframe from WIN 2000 using MQCHLTAB.I would be appreciated if you can help me resolve this issue.I have followed the direction of creating this table according to theClient book chapter 8, 9, and the Intercommunication.When I run the sample program "amqsputc" I get error code 2058 (MQCONN).This tell me that there is a problem with my channel table definitions:Here are the steps I am taking to do this process.1. I created the MQCHLTAB file using MAKECLNT for CLNTCONN as followsThis file attributes is blksize=2048, lrecl=2048, RECFM=U""//MAKECL EXEC PGM=CSQUTIL,REGION=4096K,// PARM='MQI2'//STEPLIB DD DSN=SYS91.MQ.SCSQANLE,DISP=SHR// DD DSN=SYS91.MQ.SCSQAUTH,DISP=SHR//OUTCLNT DD DISP=MOD,DSN=MQ.CL.TAB1//SYSPRINT DD SYSOUT=*//SYSIN DD *COMMAND DDNAME(CMDCHL) MAKECLNT(OUTCLNT)/*//CMDCHL DD *DISPLAY CHANNEL(WAS.SVR) ALL TYPE(CLNTCONN)2. I ftp the file to WIN 2000 using Binary option.I read the file using notepad and I can see the channel definitionsand at the end has garbage as well.3. I set the Environment variable in my PC as follows:SET MQCHLLIB = MQCHLTAB.TAB which is the name of my binary file thatI FTP from mainframe.4. I setup Environment variable also for the path asMQCHLLIB = C:\mqm\This is the path for the MQCHLTAB.TAB.THANK YOU FOR YOUR HELP.Do you Yahoo!?Yahoo! SiteBuilder - Free web site building tool. Try it!Instructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online
Re: Problems starting config manager for WMQI v2.1
Title: Message Steve..your my hero! (funny though that I had it running before ok.still, learning not to ask questions!) -Original Message-From: GIES, STEVE [mailto:[EMAIL PROTECTED] Sent: 05 February 2004 16:53To: [EMAIL PROTECTED]Subject: Re: Problems starting config manager for WMQI v2.1 Peter - Is the userid that the ConfigMgr NT Service runs under (mqsiuid in your example) a member of the "administrators" group on the server? I seem to recall getting this error if it is not. - Steve -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Moir, PeterSent: Thursday, February 05, 2004 6:56 AMTo: [EMAIL PROTECTED]Subject: Problems starting config manager for WMQI v2.1 Hi, been running the config. manager for a few days now without problems. Today I had occasion to stop it. When I restarted it I got…. "Missing or blank message repository database name" Checked windows registry and then relevant entry is correctly filled out. So I stopped it again and deleted it. Then I created it again with command…. mqsicreateconfigmgr -I mqsiuid -a mqsipw -q CM_QMGR -n MQSICMDB -m MQSIRMDB Created ok, no errors. Start the config manager and I get the same error…….."Missing or blank message repository database name" But the entry in the registry after the create is fine - shows MQSIRMDB. DB and tables also check out in DB2. Tried this a few times now, no joy. Any ideas? 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. 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.
Re: Looking for your thoughts, please
Dave, We use DASD logging, and then let DFHSM migrate the archive logs to tape after 1 day. They are kept for 14 days and then rolled off. We found this to be a much cleaner process and don't fill up the DASD or use unnecessary tapes. We modeled the migrate off of our IMS and DB2 archives. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Williams, Dave (Systems Management)" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 02/05/04 08:51 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Looking for your thoughts, please Presently, one of our more active QMGRs is set up w/four primary and secondary logs – each 1000 cyls. We then archive to tape. The size of the logs and the all over process is performing well. However, management has raised the issue of when we have to apply maintenance to our tape system we are required to quiesce MQ, for fear that the logs will fill, archiving (tape system down) won't work and we'll be in a fine mess. And during even non-peak times the logs switch often. We could 1) go to DASD archiving, but it seems to me a lot of resource required in pool DASD – plus it would still have to archive to tape in time (which I don't think would be long) anyway. 2) Switch to DASD archiving only during these maint. periods, but this requires a sort of baby sitting approach – make the parm change, keep an eye on the archives filling up… kind of a drag. 3) Stay as we are (I like this one) – just ensure that the tape maint. is done during our usual bi-weekly maint. window. Your thoughts are appreciated – since we've increased the number of and resized our logs the whole process has been problem free and very smooth. Thanks, Dave The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: Problems starting config manager for WMQI v2.1
Title: Message Peter - Is the userid that the ConfigMgr NT Service runs under (mqsiuid in your example) a member of the "administrators" group on the server? I seem to recall getting this error if it is not. - Steve -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Moir, PeterSent: Thursday, February 05, 2004 6:56 AMTo: [EMAIL PROTECTED]Subject: Problems starting config manager for WMQI v2.1 Hi, been running the config. manager for a few days now without problems. Today I had occasion to stop it. When I restarted it I got…. "Missing or blank message repository database name" Checked windows registry and then relevant entry is correctly filled out. So I stopped it again and deleted it. Then I created it again with command…. mqsicreateconfigmgr -I mqsiuid -a mqsipw -q CM_QMGR -n MQSICMDB -m MQSIRMDB Created ok, no errors. Start the config manager and I get the same error…….."Missing or blank message repository database name" But the entry in the registry after the create is fine - shows MQSIRMDB. DB and tables also check out in DB2. Tried this a few times now, no joy. Any ideas? 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.
Re: Process /sys$system/runmqchl terminated with status 20
I believe the default number of channel initiators is 3. The maxinitiators setting may not be the source of your problem - I mentioned it solely since it had an error return of 20. If you are attempting to run more than the default 3 channel initiators then perhaps this setting may be of assistance. Do the error logs contain any information regarding lack of resources? -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of David Awerbuch Sent: Thursday, February 05, 2004 09:16 To: [EMAIL PROTECTED] Subject: Re: Process /sys$system/runmqchl terminated with status 20 Ken, There is no 'maxinitiators' clause in the [channels] stanza. Does anyone know what the default value is? I have other systems (2.2.1) with more channels running than this 5.1.0 system has, so I don't properly understand why this would be a problem now. Thanks, Dave A. -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: Sunday, February 04, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Process /sys$system/runmqchl terminated with status 20 I've seen error status 20 occur on a queue manager when the "maxinitiators" was set too low to accomodate all requested channel initiators. This would be set in the channels stanza in the file qm.ini. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Arlen Sent: Wednesday, February 04, 2004 12:00 To: [EMAIL PROTECTED] Subject: Re: Process /sys$system/runmqchl terminated with status 20 Error 20 on a VMS system is BADPARM, bad parameter value. -Original Message- From: David Awerbuch [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 9:18 AM To: [EMAIL PROTECTED] Subject: Process /sys$system/runmqchl terminated with status 20 Hello, I am logged on as user MQADMIN, with MQM rights, on an Alpha/OpenVMS 7.3 system running WMQ 5.1.0, ECO02. I am receiving the following operator message about every minute, with occasionally gaps of from 5 to 25 minutes. Reply received on ATP023 from user MQADMIN at ATP023 Batch 11:53:18 Process /sys$system/runmqchl terminated with status 20 Does anyone have any ideas what this is all about? I can not find a reference to this message or the status 20. Thanks, Dave A. = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html 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: Looking for your thoughts, please
Title: Message Dave Archive to properly sized DASD SMS managed pool and let DFHSM migrate to compressed tape directly is one option. This will work for what you need. Best of luck Frank -Original Message-From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Williams, Dave (Systems Management)Sent: Thursday, February 05, 2004 8:51 AMTo: [EMAIL PROTECTED]Subject: Looking for your thoughts, please Presently, one of our more active QMGRs is set up w/four primary and secondary logs - each 1000 cyls. We then archive to tape. The size of the logs and the all over process is performing well. However, management has raised the issue of when we have to apply maintenance to our tape system we are required to quiesce MQ, for fear that the logs will fill, archiving (tape system down) won't work and we'll be in a fine mess. And during even non-peak times the logs switch often. We could 1) go to DASD archiving, but it seems to me a lot of resource required in pool DASD - plus it would still have to archive to tape in time (which I don't think would be long) anyway. 2) Switch to DASD archiving only during these maint. periods, but this requires a sort of baby sitting approach - make the parm change, keep an eye on the archives filling up... kind of a drag. 3) Stay as we are (I like this one) - just ensure that the tape maint. is done during our usual bi-weekly maint. window. Your thoughts are appreciated - since we've increased the number of and resized our logs the whole process has been problem free and very smooth. Thanks, Dave This e-mail message and any attachments contain confidential information from Medco Health Solutions, Inc. If you are not the intended recipient, you are hereby notified that disclosure, printing, copying, distribution, or the taking of any action in reliance on the contents of this electronic information is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender by reply message and then delete the electronic message and any attachments.
Problems starting config manager for WMQI v2.1
Title: Problems starting config manager for WMQI v2.1 Hi, been running the config. manager for a few days now without problems. Today I had occasion to stop it. When I restarted it I got…. "Missing or blank message repository database name" Checked windows registry and then relevant entry is correctly filled out. So I stopped it again and deleted it. Then I created it again with command…. mqsicreateconfigmgr -I mqsiuid -a mqsipw -q CM_QMGR -n MQSICMDB -m MQSIRMDB Created ok, no errors. Start the config manager and I get the same error…….."Missing or blank message repository database name" But the entry in the registry after the create is fine - shows MQSIRMDB. DB and tables also check out in DB2. Tried this a few times now, no joy. Any ideas? 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.
Re: Just an informal survey slightly off topic
Exactly. We also plan to cutover to z/OS later this year. Nick Dilauro <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: Just an informal survey slightly off topic MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/04/2004 05:50 PM Please respond to MQSeries List I believe OS/390 2.10 goes out of service in September 2004, but it may be a better migration path to ZOS. Nick -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Tsujimoto Sent: Wednesday, February 04, 2004 2:32 PM To: [EMAIL PROTECTED] Subject: Re: Just an informal survey slightly off topic We're still runnning CICS/ESA V4.1 in production (and MQ 1.2, OS/390 2.6,...), but management finally agreed it was a good idea to go to a supported version (for everything). So, sometime in the next month or so, we're going to cutover to CICSTS 2.2 (and OS/390 2.10, MQ V5.3.1, and so forth). Everything brand spanking new. Ronald Weinger <[EMAIL PROTECTED] To: [EMAIL PROTECTED] E.COM> cc: Sent by: Subject: Just an informal survey slightly off topic MQSeries List <[EMAIL PROTECTED] en.AC.AT> 02/04/2004 07:14 AM Please respond to MQSeries List IBM is continuing support of CICS/TS 1.3 into 2006. Is your company making a big effort to move to TS 2.2? 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. 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: MQSeries 5.3 on XP
You need the version that comes with CSD01 on the installation CD. If it is the GA version, it won't install. Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Kerry Swemmer [mailto:[EMAIL PROTECTED] Sent: 05 February 2004 13:45 To: [EMAIL PROTECTED] Subject: MQSeries 5.3 on XP Hi All, I am trying to install 5.3 on Windows XP and am getting the following AMQ4755 This version of IBM WebSphere MQ does not yet support Windows XP. A CSD will provide this support. Any ideas? I cannot find any related CSD. Thanx, Kerry. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John Scott Sent: 18 November 2003 10:49 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? You still get an improvement by using syncpoint after every message. The test I did reduced the time for 1000 persistent messages from 25 to 15 seconds... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 19:03 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Paul, Thanks for the response. But the requirement is that we have to do a commit after every persistent message read off the queue (as opposed to after a batch of messages read). Thanks, Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > Depends what you mean by 'impact'. I assume you're > talking about persistent > messages here. Generally speaking the addition of > syncpoint to persistent > message operations will increase the performance > since we only need to > force the log at commit time rather than for every > message. > > Download my MA01 support pac if you want to have a > play. > Choose a local queue, say Q1 > Load the queue with messages :- > > q -oQ1 -ap > > at the prompt type > #1000 > > you now have 1000 persistent messages on your queue. > > Get them off by specifying :- > > q -IQ1 -t -q > > this will printout something like > > 1000 Interations in 441.00 ms, Average = 0.44ms or > 2267.6 per second > > This is doing your gets outside of syncpoint. > To do it inside of syncpoint you can tell queue how > often to commit, let's > say every 100 messages > > Load up your queue again and then type > > q -IQ1 -t -q -p100 > > The line now reads > 1000 Interations in 90.00 ms, Average = 0.09ms or > 1.1 per second > > By doing the gets under syncpoint (and quite a lot > of them) we're now about > 5 times faster. > > These were the numbers produced on my ThinkPad and > will depend greatly on > the speed of your disks, the type of disks, your CPU > speed etc etc. > > There are also, I believe, a number of support pacs > which detail the speed > of MQ operations on the support pac website. > > Hope this helps, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | N.AC.AT> | > | || > | || > | | 17/11/2003 16:59 | > | | Please respond to| > | | MQSeries List| > |-+> > > >--- > | > | > > | > | To: [EMAIL PROTECTED] > > | > | cc: > > | > | Subject: Impact of Syncpoint? > > | > | > > | > | > > | > > >--- > | > > > > MQ 5.3/W2K I have been asked to find out the > "performance impact" of using Syncpoint in MQGETs. > Is > there a document around that deals with this issue? > > Thanks, > > Ruzi > > 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 *** 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 confidentia
Re: Process /sys$system/runmqchl terminated with status 20
Ken, There is no 'maxinitiators' clause in the [channels] stanza. Does anyone know what the default value is? I have other systems (2.2.1) with more channels running than this 5.1.0 system has, so I don't properly understand why this would be a problem now. Thanks, Dave A. -Original Message- From: Ken Woloschuk [mailto:[EMAIL PROTECTED] Sent: Sunday, February 04, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Process /sys$system/runmqchl terminated with status 20 I've seen error status 20 occur on a queue manager when the "maxinitiators" was set too low to accomodate all requested channel initiators. This would be set in the channels stanza in the file qm.ini. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Williams, Arlen Sent: Wednesday, February 04, 2004 12:00 To: [EMAIL PROTECTED] Subject: Re: Process /sys$system/runmqchl terminated with status 20 Error 20 on a VMS system is BADPARM, bad parameter value. -Original Message- From: David Awerbuch [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 9:18 AM To: [EMAIL PROTECTED] Subject: Process /sys$system/runmqchl terminated with status 20 Hello, I am logged on as user MQADMIN, with MQM rights, on an Alpha/OpenVMS 7.3 system running WMQ 5.1.0, ECO02. I am receiving the following operator message about every minute, with occasionally gaps of from 5 to 25 minutes. Reply received on ATP023 from user MQADMIN at ATP023 Batch 11:53:18 Process /sys$system/runmqchl terminated with status 20 Does anyone have any ideas what this is all about? I can not find a reference to this message or the status 20. Thanks, Dave A. = David A. Awerbuch, IBM Certified MQSeries Specialist APC Consulting Services, Inc. Providing Automated Solutions to Business Challenges West Hempstead, NY(516) 481-6440 [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQSeries 5.3 on XP
Hi, WebSphere MQ 5.3 GA does not support XP. Then, to install it, just install mq with the following command line and install the latest csd. x:\setup.exe AMQ_XP_INSTALL_PENDING_CSD=1 You could also take a look to http://www-1.ibm.com/support/docview.wss?uid=swg27004410&aid=1 which is the latest CSD readme file. > -Mensaje original- > De: Kerry Swemmer [SMTP:[EMAIL PROTECTED] > Enviado el: Thursday, 05 February, 2004 2:45 PM > Para: [EMAIL PROTECTED] > Asunto: MQSeries 5.3 on XP > > Hi All, > > I am trying to install 5.3 on Windows XP and am getting the following > > AMQ4755 This version of IBM WebSphere MQ > does not yet support Windows XP. A > CSD will provide this support. > > Any ideas? I cannot find any related CSD. > > Thanx, > Kerry. > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John > Scott > Sent: 18 November 2003 10:49 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > You still get an improvement by using syncpoint after every message. The > test I did reduced the time for 1000 persistent messages from 25 to 15 > seconds... > > Regards > John Scott > IBM Certified Specialist - MQSeries > Argos Ltd > > > -Original Message- > From: Ruzi R [mailto:[EMAIL PROTECTED] > Sent: 17 November 2003 19:03 > To: [EMAIL PROTECTED] > Subject: Re: Impact of Syncpoint? > > > Paul, > > Thanks for the response. But the requirement is that > we have to do a commit after every persistent message > read off the queue (as opposed to after a batch of > messages read). > > Thanks, > > Ruzi > > --- Paul Clarke <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'impact'. I assume you're > > talking about persistent > > messages here. Generally speaking the addition of > > syncpoint to persistent > > message operations will increase the performance > > since we only need to > > force the log at commit time rather than for every > > message. > > > > Download my MA01 support pac if you want to have a > > play. > > Choose a local queue, say Q1 > > Load the queue with messages :- > > > > q -oQ1 -ap > > > > at the prompt type > > #1000 > > > > you now have 1000 persistent messages on your queue. > > > > Get them off by specifying :- > > > > q -IQ1 -t -q > > > > this will printout something like > > > > 1000 Interations in 441.00 ms, Average = 0.44ms or > > 2267.6 per second > > > > This is doing your gets outside of syncpoint. > > To do it inside of syncpoint you can tell queue how > > often to commit, let's > > say every 100 messages > > > > Load up your queue again and then type > > > > q -IQ1 -t -q -p100 > > > > The line now reads > > 1000 Interations in 90.00 ms, Average = 0.09ms or > > 1.1 per second > > > > By doing the gets under syncpoint (and quite a lot > > of them) we're now about > > 5 times faster. > > > > These were the numbers produced on my ThinkPad and > > will depend greatly on > > the speed of your disks, the type of disks, your CPU > > speed etc etc. > > > > There are also, I believe, a number of support pacs > > which detail the speed > > of MQ operations on the support pac website. > > > > Hope this helps, > > P. > > > > Paul G Clarke > > WebSphere MQ Development > > IBM Hursley > > > > > > > > |-+> > > | | Ruzi R | > > | | <[EMAIL PROTECTED]| > > | | M> | > > | | Sent by: MQSeries| > > | | List | > > | | <[EMAIL PROTECTED]| > > | | N.AC.AT> | > > | || > > | || > > | | 17/11/2003 16:59 | > > | | Please respond to| > > | | MQSeries List| > > |-+> > > > > > >- > -- > | > > | > > > > | > > | To: [EMAIL PROTECTED] > > > > | > > | cc: > > > > | > > | Subject: Impact of Syncpoint? > > > > | > > | > > > > | > > | > > > > | > > > > > >- > -- > | > > > > > > > > MQ 5.3/W2K I have been asked to find out the > > "performance impact" of using Syncpoint in MQGETs. > > Is > > there a document around that deals with this issue? > > > > Thanks, > > > > Ruzi > > > > 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:/
Re: MQSeries 5.3 on XP
If it is XP Pro, and it still wont work, maybe this is a solution? http://www.mqseries.net/phpBB2/viewtopic.php?t=10534&highlight=csd01 -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 8:54 AM To: [EMAIL PROTECTED] Subject: Re: MQSeries 5.3 on XP Is it XP Pro or XP Home? Pro is supported. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Swemmer Sent: Thursday, February 05, 2004 8:45 AM To: [EMAIL PROTECTED] Subject: MQSeries 5.3 on XP Hi All, I am trying to install 5.3 on Windows XP and am getting the following AMQ4755 This version of IBM WebSphere MQ does not yet support Windows XP. A CSD will provide this support. Any ideas? I cannot find any related CSD. Thanx, Kerry. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John Scott Sent: 18 November 2003 10:49 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? You still get an improvement by using syncpoint after every message. The test I did reduced the time for 1000 persistent messages from 25 to 15 seconds... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 19:03 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Paul, Thanks for the response. But the requirement is that we have to do a commit after every persistent message read off the queue (as opposed to after a batch of messages read). Thanks, Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > Depends what you mean by 'impact'. I assume you're > talking about persistent > messages here. Generally speaking the addition of > syncpoint to persistent > message operations will increase the performance > since we only need to > force the log at commit time rather than for every > message. > > Download my MA01 support pac if you want to have a > play. > Choose a local queue, say Q1 > Load the queue with messages :- > > q -oQ1 -ap > > at the prompt type > #1000 > > you now have 1000 persistent messages on your queue. > > Get them off by specifying :- > > q -IQ1 -t -q > > this will printout something like > > 1000 Interations in 441.00 ms, Average = 0.44ms or > 2267.6 per second > > This is doing your gets outside of syncpoint. > To do it inside of syncpoint you can tell queue how > often to commit, let's > say every 100 messages > > Load up your queue again and then type > > q -IQ1 -t -q -p100 > > The line now reads > 1000 Interations in 90.00 ms, Average = 0.09ms or > 1.1 per second > > By doing the gets under syncpoint (and quite a lot > of them) we're now about > 5 times faster. > > These were the numbers produced on my ThinkPad and > will depend greatly on > the speed of your disks, the type of disks, your CPU > speed etc etc. > > There are also, I believe, a number of support pacs > which detail the speed > of MQ operations on the support pac website. > > Hope this helps, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | N.AC.AT> | > | || > | || > | | 17/11/2003 16:59 | > | | Please respond to| > | | MQSeries List| > |-+> > > >--- > | > | > > | > | To: [EMAIL PROTECTED] > > | > | cc: > > | > | Subject: Impact of Syncpoint? > > | > | > > | > | > > | > > >--- > | > > > > MQ 5.3/W2K I have been asked to find out the > "performance impact" of using Syncpoint in MQGETs. > Is > there a document around that deals with this issue? > > Thanks, > > Ruzi > > 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: MQSeries 5.3 on XP
Is it XP Pro or XP Home? Pro is supported. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Kerry Swemmer Sent: Thursday, February 05, 2004 8:45 AM To: [EMAIL PROTECTED] Subject: MQSeries 5.3 on XP Hi All, I am trying to install 5.3 on Windows XP and am getting the following AMQ4755 This version of IBM WebSphere MQ does not yet support Windows XP. A CSD will provide this support. Any ideas? I cannot find any related CSD. Thanx, Kerry. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John Scott Sent: 18 November 2003 10:49 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? You still get an improvement by using syncpoint after every message. The test I did reduced the time for 1000 persistent messages from 25 to 15 seconds... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 19:03 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Paul, Thanks for the response. But the requirement is that we have to do a commit after every persistent message read off the queue (as opposed to after a batch of messages read). Thanks, Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > Depends what you mean by 'impact'. I assume you're > talking about persistent > messages here. Generally speaking the addition of > syncpoint to persistent > message operations will increase the performance > since we only need to > force the log at commit time rather than for every > message. > > Download my MA01 support pac if you want to have a > play. > Choose a local queue, say Q1 > Load the queue with messages :- > > q -oQ1 -ap > > at the prompt type > #1000 > > you now have 1000 persistent messages on your queue. > > Get them off by specifying :- > > q -IQ1 -t -q > > this will printout something like > > 1000 Interations in 441.00 ms, Average = 0.44ms or > 2267.6 per second > > This is doing your gets outside of syncpoint. > To do it inside of syncpoint you can tell queue how > often to commit, let's > say every 100 messages > > Load up your queue again and then type > > q -IQ1 -t -q -p100 > > The line now reads > 1000 Interations in 90.00 ms, Average = 0.09ms or > 1.1 per second > > By doing the gets under syncpoint (and quite a lot > of them) we're now about > 5 times faster. > > These were the numbers produced on my ThinkPad and > will depend greatly on > the speed of your disks, the type of disks, your CPU > speed etc etc. > > There are also, I believe, a number of support pacs > which detail the speed > of MQ operations on the support pac website. > > Hope this helps, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | N.AC.AT> | > | || > | || > | | 17/11/2003 16:59 | > | | Please respond to| > | | MQSeries List| > |-+> > > >--- > | > | > > | > | To: [EMAIL PROTECTED] > > | > | cc: > > | > | Subject: Impact of Syncpoint? > > | > | > > | > | > > | > > >--- > | > > > > MQ 5.3/W2K I have been asked to find out the > "performance impact" of using Syncpoint in MQGETs. > Is > there a document around that deals with this issue? > > Thanks, > > Ruzi > > 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 *** 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
Looking for your thoughts, please
Title: Looking for your thoughts, please Presently, one of our more active QMGRs is set up w/four primary and secondary logs – each 1000 cyls. We then archive to tape. The size of the logs and the all over process is performing well. However, management has raised the issue of when we have to apply maintenance to our tape system we are required to quiesce MQ, for fear that the logs will fill, archiving (tape system down) won’t work and we’ll be in a fine mess. And during even non-peak times the logs switch often. We could 1) go to DASD archiving, but it seems to me a lot of resource required in pool DASD – plus it would still have to archive to tape in time (which I don’t think would be long) anyway. 2) Switch to DASD archiving only during these maint. periods, but this requires a sort of baby sitting approach – make the parm change, keep an eye on the archives filling up… kind of a drag. 3) Stay as we are (I like this one) – just ensure that the tape maint. is done during our usual bi-weekly maint. window. Your thoughts are appreciated – since we’ve increased the number of and resized our logs the whole process has been problem free and very smooth. Thanks, Dave
MQSeries 5.3 on XP
Hi All, I am trying to install 5.3 on Windows XP and am getting the following AMQ4755 This version of IBM WebSphere MQ does not yet support Windows XP. A CSD will provide this support. Any ideas? I cannot find any related CSD. Thanx, Kerry. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of John Scott Sent: 18 November 2003 10:49 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? You still get an improvement by using syncpoint after every message. The test I did reduced the time for 1000 persistent messages from 25 to 15 seconds... Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd -Original Message- From: Ruzi R [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 19:03 To: [EMAIL PROTECTED] Subject: Re: Impact of Syncpoint? Paul, Thanks for the response. But the requirement is that we have to do a commit after every persistent message read off the queue (as opposed to after a batch of messages read). Thanks, Ruzi --- Paul Clarke <[EMAIL PROTECTED]> wrote: > Depends what you mean by 'impact'. I assume you're > talking about persistent > messages here. Generally speaking the addition of > syncpoint to persistent > message operations will increase the performance > since we only need to > force the log at commit time rather than for every > message. > > Download my MA01 support pac if you want to have a > play. > Choose a local queue, say Q1 > Load the queue with messages :- > > q -oQ1 -ap > > at the prompt type > #1000 > > you now have 1000 persistent messages on your queue. > > Get them off by specifying :- > > q -IQ1 -t -q > > this will printout something like > > 1000 Interations in 441.00 ms, Average = 0.44ms or > 2267.6 per second > > This is doing your gets outside of syncpoint. > To do it inside of syncpoint you can tell queue how > often to commit, let's > say every 100 messages > > Load up your queue again and then type > > q -IQ1 -t -q -p100 > > The line now reads > 1000 Interations in 90.00 ms, Average = 0.09ms or > 1.1 per second > > By doing the gets under syncpoint (and quite a lot > of them) we're now about > 5 times faster. > > These were the numbers produced on my ThinkPad and > will depend greatly on > the speed of your disks, the type of disks, your CPU > speed etc etc. > > There are also, I believe, a number of support pacs > which detail the speed > of MQ operations on the support pac website. > > Hope this helps, > P. > > Paul G Clarke > WebSphere MQ Development > IBM Hursley > > > > |-+> > | | Ruzi R | > | | <[EMAIL PROTECTED]| > | | M> | > | | Sent by: MQSeries| > | | List | > | | <[EMAIL PROTECTED]| > | | N.AC.AT> | > | || > | || > | | 17/11/2003 16:59 | > | | Please respond to| > | | MQSeries List| > |-+> > > >--- | > | > > | > | To: [EMAIL PROTECTED] > > | > | cc: > > | > | Subject: Impact of Syncpoint? > > | > | > > | > | > > | > > >--- | > > > > MQ 5.3/W2K I have been asked to find out the > "performance impact" of using Syncpoint in MQGETs. > Is > there a document around that deals with this issue? > > Thanks, > > Ruzi > > 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 *** 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 us
