Re: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8
Actually, I thbought I remembered seeing this documented somewhere. It's in the MQ Security manual (p 47 in the edition I have) under SSL Support where it ralks about the SSL key respository. It says the key databse must have a file extension .kdb -Original Message- From: Bullock, Rebecca (CSC) Sent: Thursday, August 19, 2004 10:57 AM To: 'MQSeries List' Subject: RE: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmdfailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Raj, I don't know if this is it, but try using the extension .kdb for the key database. Here's what I used for mine and it worked (gsk at 6.0.5.39); the file extension looks like the only real difference: gsk6cmd -keydb -create -db $dbdir/key.kdb -type cms -stash I'd agree about the doc. It's not too bad (I guess) if you have a gui (at least, there are lots of pictures), but the line command doc leaves a bit to the imagination. -- Rebecca -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: AW: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmdfailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi Raj, I strongly recommend, to follow the quick beginnings document. Be sure, that the prerequisites for SSL support are installed. Regards Hubert -Ursprungliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Rajesh-IT Sharma Gesendet: Donnerstag, 19. August 2004 15:27 An: [EMAIL PROTECTED] Betreff: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmd failed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi, I have seen few posts related to this topic on other forums, but haven't found a solution yet. Here is what I am trying to do- Env: Sun Solaris V 2.8 MQ Series V5.3 CSD with mqm-upd05 U487899 GSKit Info: (#)ProductName: gsk6e (GoldCoast Build) 0406171803 @(#)ProductVersion: 6.0.5.43 @(#)ProductInfo: 04/06/15.00:00:28.04/06/17.18:11:04 @(#)CMVCInfo: gsk6e_040615/gsk6e_ikm gsk6e_040615/gsk6e_ssl gsk6e_040615/gsk6e_support gsk6e_040615/gsk6e_cms NOTE: All the required Solaris patches mentioned in memo.ptf is in place. CLASSPATH /opt/mqm/ssl/lib/tools.jar:/opt/mqm/ssl/lib/i18n.jar:/opt/ibm/gsk6/classes/c fwk.zip:/opt/ibm/gsk6/classes/gsk6cls.jar:/opt/mqm/java/lib/com.ibm.mq.jar:/ opt/mqm/java/lib/com.ibm.mqbind.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt /mqm/java/lib/fscontext.jar:/opt/mqm/java/lib/ldap.jar:/opt/mqm/java/lib/pro viderutil.jar:/opt/mqm/java/lib/jms.jar:/opt/mqm/java/lib/jndi.jar:/opt/mqm/ java/lib/jta.jar:/opt/mqm/java/lib/connector.jar:. PATH /opt/mqm/ssl/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/EMCpower/bin:/etc:/opt/m qm/java/lib:/data/oracle/product/8.1.7.4/bin:. JAVA_HOME=/opt/mqm/ssl Problem: Creation of Key database of type "cms" failed: $gsk6cmd -keydb -create -db keys -pw passw0rd -type cms -expire 3660 -stash Invalid key database type was found. Other Things Tried (to prove that I am trying my best to get this thing to work) a. Able to create keydb of type "jks" - Proves that GSKit is installed and works b. Used -covert option to convert the "jks" db to "cms" type. To see if the -create option only has this problem. But, it failed giving the same error too. "Invalid key database type was found." Anyone has tried and succeeded in doing this - please provide some pointer as to what is wrong. IBM documentation on GSKit is bare minimum... Thank you. Raj 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 ** 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: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmdf ailed for -type cms GSKit V6.0.5.43 Solaris 2.8
Raj, I don't know if this is it, but try using the extension .kdb for the key database. Here's what I used for mine and it worked (gsk at 6.0.5.39); the file extension looks like the only real difference: gsk6cmd -keydb -create -db $dbdir/key.kdb -type cms -stash I'd agree about the doc. It's not too bad (I guess) if you have a gui (at least, there are lots of pictures), but the line command doc leaves a bit to the imagination. -- Rebecca -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:58 AM To: [EMAIL PROTECTED] Subject: AW: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmdfailed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi Raj, I strongly recommend, to follow the quick beginnings document. Be sure, that the prerequisites for SSL support are installed. Regards Hubert -Ursprungliche Nachricht- Von: MQSeries List [mailto:[EMAIL PROTECTED] Auftrag von Rajesh-IT Sharma Gesendet: Donnerstag, 19. August 2004 15:27 An: [EMAIL PROTECTED] Betreff: "Invalid key database type was found" V5.3 CSD05 SSL gsk6cmd failed for -type cms GSKit V6.0.5.43 Solaris 2.8 Hi, I have seen few posts related to this topic on other forums, but haven't found a solution yet. Here is what I am trying to do- Env: Sun Solaris V 2.8 MQ Series V5.3 CSD with mqm-upd05 U487899 GSKit Info: (#)ProductName: gsk6e (GoldCoast Build) 0406171803 @(#)ProductVersion: 6.0.5.43 @(#)ProductInfo: 04/06/15.00:00:28.04/06/17.18:11:04 @(#)CMVCInfo: gsk6e_040615/gsk6e_ikm gsk6e_040615/gsk6e_ssl gsk6e_040615/gsk6e_support gsk6e_040615/gsk6e_cms NOTE: All the required Solaris patches mentioned in memo.ptf is in place. CLASSPATH /opt/mqm/ssl/lib/tools.jar:/opt/mqm/ssl/lib/i18n.jar:/opt/ibm/gsk6/classes/c fwk.zip:/opt/ibm/gsk6/classes/gsk6cls.jar:/opt/mqm/java/lib/com.ibm.mq.jar:/ opt/mqm/java/lib/com.ibm.mqbind.jar:/opt/mqm/java/lib/com.ibm.mqjms.jar:/opt /mqm/java/lib/fscontext.jar:/opt/mqm/java/lib/ldap.jar:/opt/mqm/java/lib/pro viderutil.jar:/opt/mqm/java/lib/jms.jar:/opt/mqm/java/lib/jndi.jar:/opt/mqm/ java/lib/jta.jar:/opt/mqm/java/lib/connector.jar:. PATH /opt/mqm/ssl/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/EMCpower/bin:/etc:/opt/m qm/java/lib:/data/oracle/product/8.1.7.4/bin:. JAVA_HOME=/opt/mqm/ssl Problem: Creation of Key database of type "cms" failed: $gsk6cmd -keydb -create -db keys -pw passw0rd -type cms -expire 3660 -stash Invalid key database type was found. Other Things Tried (to prove that I am trying my best to get this thing to work) a. Able to create keydb of type "jks" - Proves that GSKit is installed and works b. Used -covert option to convert the "jks" db to "cms" type. To see if the -create option only has this problem. But, it failed giving the same error too. "Invalid key database type was found." Anyone has tried and succeeded in doing this - please provide some pointer as to what is wrong. IBM documentation on GSKit is bare minimum... Thank you. Raj 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 ** 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: migrate ma88 to MQ5.3 on solaris
Title: migrate ma88 to MQ5.3 on solaris Prince, you need to do a pkgrm. Sorry, I don't remember the package name for MA88, but if you do a pkginfo -l|grep ma88, you should find it. HTH Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 e-mail: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Jose, Prince [mailto:[EMAIL PROTECTED]Sent: Monday, August 16, 2004 9:47 AMTo: [EMAIL PROTECTED]Subject: migrate ma88 to MQ5.3 on solaris Hello! I am in the process of migrating MQ java classes in Solaris. Can somebody please tell me how to uninstall ma88 in Solaris? The 'ma88 read me' documents or the manual 'MQ using Java' does not give any information about uninstalling ma88. I tried to rename the MQ java class libraries and then tried to install mq5.3. It somehow realizes that MQ is already installed on the box and the mq53 install gets suspended. Thanks in advance, Prince ** 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: MQ Series on OS/390
Vijay,
not to ask the obvious, but did you get a clean linkedit? This message (at
least, CSV016I, and I'm assuming a typo below) is usually associated with a
linkedit problem.
-Original Message-From:
Vijay_Kannan [mailto:[EMAIL PROTECTED]Sent: Thursday, July
08, 2004 1:01 AMTo: [EMAIL PROTECTED]Subject: MQ
Series on OS/390
Hi,
I am developing a Channel Exit
program on OS/390. It is a C program which should pick up any message flowing
through the Channel and put it into another Event Queue, which is also on the
Mianframe machine.
I have compiled the program and
have created the Load Module. The name of the Data Set having the load module
has been specified in the CSQXLIB DD statement of the Channel Initiator
procedure. I have also specified the name of the load module in the "Message
Exit Name" property of the Channel. But the channel is not getting
initiated.
I tried running the program from
the Command line using the CALL 'Data Set Name(Module
name)'. The message that I get is "CVS016I REQUESTED MODULE IS NOT
EXECUTABLE". I tried also using a JCL to run the load module. Then also I am
getting the same error message. This happens only when I am running any MQ
related program.
Other simple programs in C are
running correctly. I am also getting the output
properly.
Can anybody tell me what has to be
done in this regard?
Also can anybody tell me how to
write to a member in Mainframe using a C program? I used fopen("Data set name (member name)" , "Mode") for opening the
member and fprintf for writing to the member. The
member is opening, but it is not getting updated.
Thanks and
Regards,
Vijay.
**
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: AMQOAMD and SETMQAUT
Mike if you use the -s switch for amqoamd, it creates a file with setmqaut commands in it. You just run that as a script. -Original Message- From: Ward, Mike S [mailto:[EMAIL PROTECTED] Sent: Friday, May 07, 2004 3:22 PM To: [EMAIL PROTECTED] Subject: AMQOAMD and SETMQAUT Hi all, I used AMQOAMD to save my authorities, how do you use the output as input into SETMQAUT? Has anyone worked with this before? Mike S. Ward Jr. A.V.P. Information Technology Security Service Federal Credit Union (210)476-4600 [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: Can a MQ server act as MQClient?
In Unix (at least, Solaris), you can specify that both the server and client be installed at the same time (they are options you select from a list). You cannot install the server and then go back and install the client later. This will work initially, but you'll have problems when you next put on a CSD. What happens is the list of installed options is stored in a variable as part of the package info and if you add the client later, this value is updated to list only the client. Then when you put on the next CSD, only the client code is updated; the result was very ugly. Although I suppose you could save the value in the variable, add the client, and then put the original value back. I'm not that into Solaris packages, but it sounds like it would work. Comments anyone? -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, April 29, 2004 9:36 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? It's a different install on OS/390, but a typical install on Windows installs both the client stubs and the client support, at least in my experience. Bill -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Robert Broderick Sent: Thursday, April 29, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Re: Can a MQ server act as MQClient? I not sure this is true in all install instances but on Windows and OS390 it is a different install. I am not sure on the UNIX side but would bet IBM followed the same procedure. When installing one of the first things to be done is to verify that the server connection and Client connection works to the QMGR on that box. You can do this by executing the "amqs..." and "amqs...c" samples. bobbee >From: Usha Suryadevara <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Can a MQ server act as MQClient? >Date: Wed, 28 Apr 2004 16:43:48 -0400 > > >Just curious, are you guys saying that you will install an MQ server and >then you will also install an MQ client on the same machine ? I thought MQ >Server is a super set that installs everything a client installs and a lot >more. > >But yes i know for sure that you can write an application to use MQ API >(such that it uses a client connection & server connection channel combo >thus making it a client server connection) to connect to another Queue >Manager on a different machine. I am not sure if this is what you are >looking for, but thought i would drop my few cents in just in case... > >Thanks >Usha > >At 03:29 PM 4/28/2004 -0400, you wrote: >>To be more precise about the answer, yes, you can run an MQ Client process >>on a machine that is also running a queue manager, and have that client >>access a different queue manager than the one running on the same box. >> >>Bill >>-- >>>From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Sharath >>>H V >>>Sent: Wednesday, April 28, 2004 8:26 AM >>>To: [EMAIL PROTECTED] >>>Subject: Can a MQ server act as MQClient? >>> >>> >>>All >>>I have a few questions for you in MQ . >>>We have a MQ server which is going to be used in two ways . >>>The first one would be used for connecting the two modules of the same >>>application.Here Module 1 writes on to the Local Q and Module 2 reads >>>from the Local Q . >>>The second one should be used as a client . There is a second MQServer >>>which gets the messages from an external MQserver (MQserver 3 ) Here we >>>want the first MQ server act as client to the second MQserver >>>Can I use a MQserver as a MQclient to connect to another MQ Server ? If >>>so , can i get some material on how to do the same . >>> >>> >>>image0019.gif >>> >>>rgds >>>H V SHarath >>> >>> >>> _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ 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 ** 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 Arch
Re: Message Tracking
Roger, the only thing I have to say is to agree that you want to include at least part of the actual message data. That way, if the programmer has the wrong msgid or correlid or even ends up with duplicates (if, for example, he doesn't clear these fields before his next put), you stand a chance of finding the actual message based on the data itself. -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 28, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: Message Tracking All, I have tried to talk my current client into buying a message tracking product but of course they say they don't have the money!?!?! The problem is that the client has a lot of MQ development going on with a lot of newbie MQ/Java developers. And of course the newbie developers keep telling me that MQ lost their messages. This of course is driving me nuts!!! So I figured that I would create an API Exit to log the following: - Queue Name - Date / Time - MsgID - CorrelID - GroupID >From a tracking point of view, I don't think logging the message data is important but what other fields of the MQMD should be logged?? I figure I would use Perl or Java to summarize or correlate the information in the log file. Of course, the script would cross search between MsgID, CorrelID & GroupID for matches. Any comments - thoughts about this. Regards, Roger Lacroix 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 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: Utility for pulling a single message off of a Queue
Dave, you didn't say why you want to pull it.If it's just to get rid of it and it's only an occasional thing (such as a junk message on a queue), you could try SupportPac MO71; it will delete individual messages. -- and it's free. HTH, Rebecca Rebecca Bullock Computer Sciences Corp. MFCoE/Newark Client Support Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -- and it's free. HTH, Rebecca -Original Message-From: De Seve, David [mailto:[EMAIL PROTECTED]Sent: Monday, April 19, 2004 11:46 AMTo: [EMAIL PROTECTED]Subject: Utility for pulling a single message off of a Queue Does any one have or know where I can get a Windows utility for pulling a single message off of a queue (select by Message ID)? Dave De Seve Middleware Systems Support - 52/996.69MQSeries Certified Specialist & WebSphere AdministratorMarriott International - Information ResourcesDirect Phone: 301-380-8279Cell: 202-247-7766 240-372-4848Fax: 301-380-2922 ** 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: endmqlsr after endmqm
No, it's not a big deal, Pavel. And that's what I've done in the past, using the ever popular kill -9. I'd hesitate to touch the setmqaut's since then you have to put them back. Hadn't thought of the MCAUSER -- That's a nice easy approach. But Paul's oh-so-secret flag is even easier. -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: Re: endmqlsr after endmqm Just gave it some thought.. One way to achieve that (meaning -- the maintenance mode, without bringing down listener) must be to prohibit anyone to connect to QM, with setmqaut.. Another should be to set MCAUSER in all channels to someone who cannot connect (like nobody). Also, is it so bad just to kill listener process? Pavel "Bullock, Rebecca (CSC)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: >Subject: Re: endmqlsr after endmqm Sent by: MQSeries List <[EMAIL PROTECTED] n.AC.AT> 03/26/2004 12:53 PM Please respond to MQSeries List Hi, Ian. No, I don't have the answer, but I wanted to interject another reason one might want to end the listener but not the queue manager. In some circumstances, one might wish to perform some maintenance-type work on the queue manager but not have users connecting, only allowing access through applications/programs local to the MQ server (such as runmqsc). While you can ask that users not connect (ha!), the chances are that they still will. Being able to end the listener would preclude that. I've sometimes wondered about the requirement to end the qmgr, too.. -Original Message- From: Chan, Ian M [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 10:26 PM To: [EMAIL PROTECTED] Subject: endmqlsr after endmqm Hi all, This is not a problem question. However, I am really curious to know why. Before MQ v5.3, I use UNIX listener rather than the MQ listener. Now with the upgrade to v5.3, I started to use MQ listener. Logically thinking, I start the qmgr and then the mq listener and end the listener before ending the qmgr. However, the endmqlsr command cannot be issued while qmgr is active (you will get AMQ9596 error). I have to endmqm first and then endmqlsr. On the Windows platform, I got the same AMQ9596 error if I issue endmqlsr from the Command Prompt while the qmgr is active . However I can end listener from the MQ services while the qmgr is active. Anyone know why endmqlsr cannot be issued while qmgr is active ? To me it is logical to stop listener first and then the qmgr. Besides, what is the difference between using endmqlsr from command prompt and the stop listener from MQ services in the Windows platform? Regards, Ian ** 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 may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: endmqlsr after endmqm
Hi, Ian. No, I don't have the answer, but I wanted to interject another reason one might want to end the listener but not the queue manager. In some circumstances, one might wish to perform some maintenance-type work on the queue manager but not have users connecting, only allowing access through applications/programs local to the MQ server (such as runmqsc). While you can ask that users not connect (ha!), the chances are that they still will. Being able to end the listener would preclude that. I've sometimes wondered about the requirement to end the qmgr, too.. -Original Message-From: Chan, Ian M [mailto:[EMAIL PROTECTED]Sent: Thursday, March 25, 2004 10:26 PMTo: [EMAIL PROTECTED]Subject: endmqlsr after endmqm Hi all, This is not a problem question. However, I am really curious to know why. Before MQ v5.3, I use UNIX listener rather than the MQ listener. Now with the upgrade to v5.3, I started to use MQ listener. Logically thinking, I start the qmgr and then the mq listener and end the listener before ending the qmgr. However, the endmqlsr command cannot be issued while qmgr is active (you will get AMQ9596 error). I have to endmqm first and then endmqlsr. On the Windows platform, I got the same AMQ9596 error if I issue endmqlsr from the Command Prompt while the qmgr is active . However I can end listener from the MQ services while the qmgr is active. Anyone know why endmqlsr cannot be issued while qmgr is active ? To me it is logical to stop listener first and then the qmgr. Besides, what is the difference between using endmqlsr from command prompt and the stop listener from MQ services in the Windows platform? Regards, Ian ** 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: MO71
Mike, see if you have the command server running (dspmqcsv). HTH, Rebecca
-Original Message-
From: Ward, Mike S [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 3:48 PM
To: [EMAIL PROTECTED]
Subject: Re: MO71
No, I want the connection secure. I am going to use blockip program there.
It seems to be a good fit. I am just testing the MO71 pack to see if I can
get it to manage the unix type queue managers. I changed the mcauser to a
userid that works for me. I now get a green status on MQMON. The problem I
now have is that when I do a queue list or channel list mqmon says that it
sent the request but does not get anything back to display. Is there
something else on unix that I am overlooking?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 8:29 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
>I'm not sure I understand. If my NT userid is db2admin why would it work
if
>I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
>users I designate can use it?
Mike,
Are you suggesting that MQ should *always* trust the userid sent from the
client ? This would be a dangerous thing. You can configure your SVRCONN to
use the userid passed in ( MCAUSER(' ') ) or always use a userid of your
choosing ( MCAUSER('FRED') ). Of course the ideal is that you authenticate
with your client using something like SSL and then make an informed
decision about what to set the userid to reflect the state of your known
client but in the meantime you can just set a pre-defined fixed user of
sufficient authority.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
"Ward, Mike S"
<[EMAIL PROTECTED]>To:
[EMAIL PROTECTED]
Sent by: MQSeriescc:
List Subject: Re: MO71
<[EMAIL PROTECTED]
N.AC.AT>
22/03/2004 13:15
Please respond to
MQSeries List
I'm not sure I understand. If my NT userid is db2admin why would it work if
I change the MCAUSER on the SVRCONN to mqm? How can I secure it so that
only
users I designate can use it?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 4:04 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
I'm not sure what your security policy is; whether you're using SSL,
security exits or whatever but to get things working you could change the
MCAUSER of the SVRCONN to something which has the required authority. If
your MCAUSER is blank then you are even less secure since you'll
effectively believe any userid the client cares to throw at you.
On most platforms you can switch authority events on in the Queue Manager
and then you'll get a message whenever a security check fails. This
messages details the userid and the object being checked. Personally I find
this quite useful when tracking down security violations.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
|-+>
| | "Ward, Mike S" |
| | <[EMAIL PROTECTED]>|
| | Sent by: MQSeries|
| | List |
| | <[EMAIL PROTECTED]|
| | N.AC.AT> |
| ||
| ||
| | 19/03/2004 22:20 |
| | Please respond to|
| | MQSeries List|
|-+>
>---
--|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: MO71
|
|
|
|
|
>---
--|
Thanks, I got it to work. I am also trying to connect to a SCO Unix
qmanager
and I keep getting a Error connecting via client to 'VRUQMGR3' RC(2035) Not
authorized. I tried defining the userid of the NT box that has mqmon
running
on it and then modifying that user so that it has mqm as a group but I
still
get the same message. Any thoughts?
-Original Message-
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 17, 2004 3:50 AM
To: [EMAIL PROTECTED]
Subject: Re: MO71
Mike,
MO71 supports two types of monitoring.
1/ Normal monitoring relies on a program at the remote Queue Manager to
receive the messages and send them back to the reply fields
This does therefore require a client (program) running on the remote
system
2/ Loopback monitoring allows yoiu to define a remote queue on the remote
system which just 'points' back to the originating queue.
This does not therefore require a client (program) running on the
remote system
Cheers,
P.
Paul G
Re: Question about q.exe
Thank you, Roger! I'm looking forward to that one for the next time I need it! :-) -- Rebecca -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 2:25 PM To: [EMAIL PROTECTED] Subject: Re: Question about q.exe Hi, Wow, what a setup!! Yes it does. It saves and reloads all MQMD fields. (Note: In v1.1.1, the MsgID was not restored correctly. This has been fixed in v1.1.2 - v1.1.2 should be released today!!) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting "Wyatt, T. Rob" <[EMAIL PROTECTED]>: > Hey Roger, > > I've been meaning to ask - does MQ Visual Edit preserve the MQMD, and > specifically the message context, when unloading/reloading queues? > > Thanks -- T.Rob > > -Original Message- > From: Roger Lacroix [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 09, 2004 12:34 PM > To: [EMAIL PROTECTED] > Subject: Re: Question about q.exe > > > Hi Jan, > > MQ Visual Edit can easily do what you require. Just use the Backup / > Restore > functions (rather than Import / Export). The Backup function will save all > messages that you have selected to a SINGLE file. If you want to backup all > messages in a queue then select all messages in the window (i.e. CTRL-A) > then > click Backup. > > For more information or to download a 30-day trial of MQ Visual Edit, go to: > http://www.capitalware.biz/products.html > > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.capitalware.biz > > > Quoting jan mecallon <[EMAIL PROTECTED]>: > > > Is q.exe capable of writing messages off a queue to a > > file so that the file can be used as a back-up to > > re-load the queue? I have just tried it (on Windows > > 200 MQ 5.3) and my XML message of 8K got chunked up > > into a number of smaller messages. I played around > > with the options of q.exe but could not get it to work > > the way I want. Basically, I would like to download > > the queue contents to a file (maintaining the format > > and structure of the message data) and load them onto > > the original or another queue. Is this possible? > > > > Thanks for any help. > > > > jan > > > > > > > -Oorspronkelijk bericht- > > > Van: MQSeries List [mailto:[EMAIL PROTECTED] > > > Namens jan mecallon > > > Verzonden: 09 March 2004 13:56 > > > Aan: [EMAIL PROTECTED] > > > Onderwerp: Re: How do I restore queues after > > > increasing log file size > > > > > > > > > Thanks for the info, Rao. I will keep all this in > > > mind. > > > > > > However, looks like we may have to increase the log > > > file size sooner or later as the log files are > > > getting > > > full because of very long messages (tens of > > > megabytes)and making the messages smaller is a very > > > big issue for the Putting end of the people who are > > > reluctant to do so. > > > > > > Again, my original question is, how can I restore > > > the > > > messages onto the queues after creating the queue > > > manager with a bigger log file size? Anybody? > > > > > > Thanks much. > > > > > > jan > > > --- "Adiraju, Rao" <[EMAIL PROTECTED]> wrote: > > > > It's very easy. We had a similar requirement - > > > > originally our logs were on > > > > D:\Mqseries\log folder and we have to move the > > > logs > > > > to "E" drive. Instead of > > > > going E:\Mqseries\log we decide to create > > > E:\WMQLOG > > > > folder. And this what we > > > > have done: > > > > > > > > 1) Stop the queue manager > > > > > > > > 2) Copy the D:\MQSeries\LOG\QM1 folder (which > > > > contains active folder and > > > > amqhlctl.tfh file) to E:\WMQLOG\QM1. You have to > > > do > > > > it this manually. > > > > > > > > 3) Atuhorise E:\WMQLOG folder and all subfolder to > > > > "mqm" user FULL access > > > > > > > > 4) go to regedit and change the logpath key to > > > point > > > > to this new directory > > > > > > > > 5) To make sure no confusion - renamed the old log > > > > folder (didn't remove at > > > > this stage) > > > > > > > > 6) Restart the queue manager - The queue manager > > > > will come up cleanly and if > > > > you check the properites through the services you > > > > will see the new log > > > > directory. > > > > > > > > 7) Once everything is perfect, then delete the old > > > > log folder > > > > > > > > It's very simple and few minutes job - you don't > > > > need worry about any backup > > > > etc.. > > > > > > > > Let me know if you get any problems. The key is > > > > item-3, ie: authorisations. > > > > > > > > Cheers > > > > > > > > Rao > > > > > > > > -Original Message- > > > > From: jan mecallon [mailto:[EMAIL PROTECTED] > > > > Sent: 9 March 2004 12:25 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: How do I restore queues after > > > > increasing log file size > > > > > > > > Rao, > > > > > > > > Thanks. I should mention that we have already > > > > increased the log files. I > > > > understand what you mean by changing the drive for > > > > log files (which is > > > > recommended by IBM a
Re: MO71
Mike, I'd guess it's related to the monitor function. Turn off monitoring and see if the red doesn't go away. If it does, then check the set up and security for the monitoring queue you have specified in your location. -Original Message- From: Ward, Mike S [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 2:37 PM To: [EMAIL PROTECTED] Subject: MO71 I am trying to set up MO71 on an NT/W2K platform. I set up the local queue manager in MO71 and also a remote queue manager. The local queue manger show green on the status screen. The remote queue manager shows red with an x through it. I can view items on the remote queue manager such as channels and queues and sometimes the remote shows green on the status screen but mostly it's red. I think I have the connectivity correct since I can manage the remote manager. Anyone have any idea's on this? 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 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
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: 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
Re: Just an informal survey slightly off topic
Us, too. -Original Message-From: Carroll, Y. (Yvette) [mailto:[EMAIL PROTECTED]Sent: Wednesday, February 04, 2004 7:33 AMTo: [EMAIL PROTECTED]Subject: Re: Just an informal survey slightly off topic We're still on 1.3 with no major push to TS 2.2. -Original Message-From: Ronald Weinger [mailto:[EMAIL PROTECTED]Sent: Wednesday, February 04, 2004 2:14 PMTo: [EMAIL PROTECTED]Subject: Just an informal survey slightly off topicIBM 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. This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. If verification of this email or any attachment is required, please request a hard-copy version. ** 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: WMQ on z/OS platform
Title: WMQ on z/OS platform Rao, we normally only recycle the queue managers when the system is IPLed. Usually, it's several months between IPLs. Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED]Sent: Sunday, February 01, 2004 8:45 PMTo: [EMAIL PROTECTED]Subject: WMQ on z/OS platform Hello to z/OS WMQ community I am looking for a "optimal" re-cycling period of MQ Manager started tasks on the z/OS platform (we haven't gone to Clusters and Queue sharing groups) and currently our Queue managers are running non-stop for more than 2 months. First of all, is there any such thing called "optimal" - if not what are the benefits / disadvantages of recycling it daily / weekly / monthly / Operating system IPL time/ wait until MQ Manager crashes. Given my past CICS/DB2/MQ experiences (hanging tasks, unreleased memories etc.) I prefer to see it daily if possible, and if not atleast once a week. Over to you guys for the support / bashing of my theory. Cheers Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you. ** 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: MQ Series upgrade on WINDOWS
Title: MQ Series upgrade on WINDOWS Rao, I'm sure that someone will respond with information specific to the Windows environment, but in other environments (well, at least in OS/390 and Sun Solaris), when you do the upgrade, the messages are preserved, even if you remove the old release (as long as you don't so something like simply delete the directory they're stored in). I'd guess that Windows is the same. For a free way to back up messages (safety first, even if messages ARE preserved), try the q program is SupportPac MA01 Good luck with your upgrade -- Rebecca Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Adiraju, Rao [mailto:[EMAIL PROTECTED]Sent: Wednesday, January 28, 2004 4:58 PMTo: [EMAIL PROTECTED]Subject: MQ Series upgrade on WINDOWS To all We are in the process of upgrading our MQ 521 to MQ53 on WINDOWS 2000 platform. During the conversion process, we have to preserve (and migrate) the messages from the application queues. Luckily the number of queues we are talking are 3 to 4 at the maximum. But I can't locate any utility / way to take a copy of the messages in a generic format such that we can load it back after conversion. We haven't yet decided whether to uninstall 521 and install 53 cleanly and upgrade in place. But whatever the path we take, we still need to preserve the messages (if in case something happens). So what are the ways to go about it. One option is to write a C-program to do it, but I would like to know what other sites are doing on this regard. Thanks in advance Rao Adiraju WebSphere MQ Specialist The National Bank of NZ Ltd. Tel: +64-4-494 4299 Fax: +64-4-802 8509 Mbl: +64-211-216-116 This communication is confidential and may contain privileged material. If you are not the intended recipient you must not use, disclose, copy or retain it. If you have received it in error please immediately notify me by return email and delete the emails.Thank you. ** 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: Channel Exits
Wesley, check for some upper/lower case mismatch with the Unix userid. I've seen that cause glitches when userids are passed to a Unix box. This may not be relevant, but it's an easy thing to look for. -Original Message- From: Jim Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 1:38 PM To: [EMAIL PROTECTED] Subject: Re: Channel Exits This really should work without coding exits. My Windows ID is "nthomdom01\ford". When I connect to Unix as a client, authentication is done using my Unix "ford" ID just fine. I can secure queues based on ford's group membership. We have spaces in the SVRCONN's MCAUSER field, an we don't use exits, just vanilla MQ. This really should work. I'd think that using exits should be a last resort. "Dawson, John" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IGROUP.COM> cc: Sent by: MQSeries Subject: Re: Channel Exits List <[EMAIL PROTECTED] .AC.AT> 01/14/2004 12:15 PM Please respond to MQSeries List Wesley, Are you trying to send a message to the UNIX system from the Windows environment without defining the Windows user id to the UNIX system and not hard coding the UNIX user id in the channel MCAUSER parameter? Thanks, John -Original Message- From: Wesley Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 11:44 AM To: [EMAIL PROTECTED] Subject:Re: Channel Exits Need to handle the client channel security between a Win2000 client and Unix MQ Server. I can not seem to get setmqaut to understand how to connect a Windows authenticated user ID on a unix group/userid system. They are not the same even though the ID might be the same. For example:ntdomain\wesley vs just wesley in unix Wesley Shaw OJRP 10th Floor Work: 804 771 3589 (736-3589) Pager: 888 436 2805 Mobile 804 512 5260 Aby Philip <[EMAIL PROTECTED]To: [EMAIL PROTECTED] GROUP.COM> cc: Sent by: MQSeriesSubject: Re: Channel Exits List <[EMAIL PROTECTED] N.AC.AT> 01/14/2004 12:26 PM Please respond to MQSeries List Hi Wesley, What kind of exits are you looking at. I mean what sort of functionality? Aby Philip -Original Message- From: MQSeries List on behalf of Wesley Shaw Sent: Wed 1/14/2004 10:46 PM To: [EMAIL PROTECTED] Cc: Subject: Re: Channel Exits 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 ** 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: Opinions requested for using MQV5.3 Local Queues as a tempora ry repository
Actually, I was thinking about this and could think of one case where it might be very desirable in batch -- If, for example, you have multiple batch jobs/TSO users and this is some shared log "file". But you still need to keep an eye on the size of those queues. Someone else out there MUST have an opinion on this one way or the other -- Anyone? -- Rebecca -Original Message----- From: Bullock, Rebecca (CSC) Sent: Monday, January 12, 2004 2:00 PM To: 'MQSeries List' Subject: RE: Opinions requested for using MQV5.3 Local Queues as a temporary repository Amy, do I understand this correctly? In a strictly batch environment, you want to use a queue as, basically, a database to stash stuff for a while. Why? With batch, wouldn't it be as simple to just MOD onto the end of a normal flat file? Yes, this will work; we have some applications that do this, although from a CICS program. If you do this, be sure to keep a close eye on the queue depths and be sure that there's some process in place to offload the data. Otherwise, you're likely to see issues with the queues taking over your DASD and filling up your pagesets in zOS (believe me, that's not a pretty picture) and taking over your hard drive on Solaris. Just my opinion; I'm sure that others will chime in. Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Amy Rech [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Opinions requested for using MQV5.3 Local Queues as a temporary repository I would appreciate hearing your expert opinions regarding using local queues as a temporary repository for persistent data. The queues reside on Unix Sun Solaris and z/OS Version 5.3 Queue Managers and messages will be initiated through batch (no CICS) processing. Thanks in advance, Amy _ High-speed users be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 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 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: Opinions requested for using MQV5.3 Local Queues as a tempora ry repository
Amy, do I understand this correctly? In a strictly batch environment, you want to use a queue as, basically, a database to stash stuff for a while. Why? With batch, wouldn't it be as simple to just MOD onto the end of a normal flat file? Yes, this will work; we have some applications that do this, although from a CICS program. If you do this, be sure to keep a close eye on the queue depths and be sure that there's some process in place to offload the data. Otherwise, you're likely to see issues with the queues taking over your DASD and filling up your pagesets in zOS (believe me, that's not a pretty picture) and taking over your hard drive on Solaris. Just my opinion; I'm sure that others will chime in. Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Amy Rech [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Opinions requested for using MQV5.3 Local Queues as a temporary repository I would appreciate hearing your expert opinions regarding using local queues as a temporary repository for persistent data. The queues reside on Unix Sun Solaris and z/OS Version 5.3 Queue Managers and messages will be initiated through batch (no CICS) processing. Thanks in advance, Amy _ High-speed users be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 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 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: Suppressing Error messages
Bill, I had to do something like this for a problem we were having (not the stripping but the saving/gzipping) and may still have the script I ran. It's from a solaris system, but I'd not expect that to be a problem since it was really basic. I had logs wrapping every 15 minutes and needed some from the middle of the night. If you'd like, I can see if I can find the script. Let me know (offline). Why should you reinvent the wheel? At least it would get you started. -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Suppressing Error messages Bill, Rather than just enlarge the files, you could archive them off while filtering out the 9228 errors. At the point in time where the error logs rotate, the 03 log falls off and the 01 and 02 logs get renamed to 02 and 03 respectively. While the 01 log gets updated every 60 seconds, the 02 and 03 log timestamps change much less frequently. It would be possible to watch the directory with a script and archive the logs as they roll off by comparing these timestamps. Every time the 03 log's timestamp changes, riffle through it and save all the non-9228 errors to an archive. You would have to figure out the smallest interval you were likely to get a log rollover, reduce that a little for safety and then schedule a cron job on the result. So if you see log rollovers every hour, do your cron every half hour. Perl would make short work of stripping out the nuisance error entries. -- T.Rob -Original Message- From: Bill Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, January 09, 2004 3:42 PM To: [EMAIL PROTECTED] Subject: Suppressing Error messages The networking folks here implemented a new process that polls various ports on the network to ensure the service is up. Well, your average MQ port don't like that much, because when it wants to see a tsh header when it begins to entertain a request for a new connection. The absence of that header in the protocol doing the polling, causes an 9228 error to be written to the error logs (every 60 seconds!). So, If there is a problem late on say Friday night, and 2nd level support is able to fix it I may not hear about it until Monday morning. By then, my friends in networking have ensured all evidence of the problem has been flushed from the error logs. I would love to find a way to suppress logging of the AMQ9228 errors. IBM suggested exporting the environmental variable MQ_CHANNEL_SUPPRESS_MSGS=9228 to do what I want done. Well, it don't work. I think its because that variable is to suppress channel error codes and this is coming from the listener, not the MCA. I think there is a way to increase the size of the logs on an AIX box, but I'll have to find it in my notes some place, I don't believe that's in the manuals. Besides all that dose is make more room for more junk. That's better than loosing potentially important errors from my logs, but I don't like it much. Anyone have a better idea? Bill Anderson Senior Systems Analyst SITA Atlanta, GA 770-303-3503 (office) 404-915-3190 (cell) [EMAIL PROTECTED] http://www.mconnect.aero/ Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: Do go looking for FDCs when "nothing" is wrong?
Peter, I bet you get responses all over the place on this one! Personally, while I usually only worry about looking at the FDCs right away at if there is a problem, I do have a script that runs regularly on each qmgr machine and checks for FDCs and lets me know if there are any. And then I will take a look at the them. And I have seen places that actively monitor the error directories for FDCs. --Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 12:04 PM To: [EMAIL PROTECTED] Subject: Do go looking for FDCs when "nothing" is wrong? I was just poking around on one server, and I happened to find a ton of FDCs. I went to look at the QA version of this server, and there were FDCs. The production version - FDCs. I started looking at other unrelated queue managers - about half had at least one FDC! Some had 20 or 30, some in one day, other spread out over the years. All are 5.3 CSD04. Both Solaris and Windows. The worst ones were the queue managers participating in Microsoft Clusters. Based on this, I feel like there is a ton of stuff that needs fixing. The first thing you do when you have major problem is go look for the inevitable FDC. BUT, everything seems fine! There are no issues, MQ keeps working, all application areas are happy. Do you guys generally go looking for problems by trying to debug FDCs? Maybe even have monitoring tools alert you anytime any FDC is created anywhere? Or unless there is a symptom of a problem elsewhere, should I just ignore them? Peter Potkay MQSeries Specialist The Hartford Financial Services [EMAIL PROTECTED] x77906 IBM MQSeries Certified This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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 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: SYSTEM.ADMIN.CHANNEL.EVENT Queue
Hi, John. Generally, a recycle of the qmgr will clear this out. Or you can clear them out yourself by reading them or using clear qlocal. A reboot isn't necessary, although that does, by default, recycle the qmgr. Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: listname ANONYMOUS postings DIGests [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:18 PM To: [EMAIL PROTECTED] Subject: SYSTEM.ADMIN.CHANNEL.EVENT Queue We use MQ on a variety of systems including Solaris, AIX, Windows, and ZOS. What clears out the SYSTEM.ADMIN.CHANNEL.EVENT queue? We have not modified the queue. Does a reboot of the server clear out the queue? Thank You, John Haraburda TPS/ITS/Database Technologies Group MQSeries - The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. 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 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: Veritas, Linux and MQ
Bobbee, check to see if Veritas provides support for Linux. They do for Solaris at V5.3 and above. -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2003 3:22 PM To: [EMAIL PROTECTED] Subject: Veritas, Linux and MQ Anybody done this? Can you use the support pack MC6A? Is there much hacking that must be done. Gotchas to look out for?? The client currently has an app using VMS Clustering. They are migrating over to Linux and have questioned the use of Veritas for the Linux box. bobbee _ Winterize your home with tips from MSN House & Home. http://special.msn.com/home/warmhome.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 ** 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: Disaster Recovery scenario for Unix box?
Hubert, it depends on the level of MQ you're running -- While earlier releases required a SupportPac to store the setmqauts (although I just added them to a file and reran the whole thing when I changed permissions), V5.3 provides a command that will create a file with the required commands. One thing I DID forget to mention is that I also take a backup of the qm.ini files for the qmgrs, so we get the changes there, too. We don't use MQ clustering, so that's not a concern. As I said, it all depends on what you want/need. Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Kleinmanns, Hubert [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 2:57 AM To: [EMAIL PROTECTED] Subject: AW: Disaster Recovery scenario for Unix box? The supportpac MS68 is also useful (and I use it). Hubert -Ursprungliche Nachricht- Von: Kleinmanns, Hubert Gesendet: Freitag, 26. September 2003 08:48 An: 'MQSeries List' Betreff: AW: Disaster Recovery scenario for Unix box? Hi Rebecca, the saveqmgr program does not store the permissions set with the setmqaut command. You need another supportpac (I guess MS0I), to save the authorities too. Nevertheless, saveqmgr stores only the qmgr configuration, not the qmgr itself. This means, you will be able, to create a qmgr with the same objects. This qmgr may have the same name, but another qmgr ID. This may cause problems when you use MQ clustering (see my mail before). Regards Hubert -Ursprungliche Nachricht----- Von: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 26. September 2003 02:21 An: [EMAIL PROTECTED] Betreff: Re: Disaster Recovery scenario for Unix box? Bill, if the only reason you're dong the backups nightly is to be sure you have the required object definitions, then why don't you just plan to create a new qmgr with the correct name and reload the objects/security stuff from the definitions? You can back those up using the saveqmgr SupportPac and the amqoamd command (OK, I may have that last one wrong since I did it from memory and I'm too tired/lazy to go look it up -- but it's at least close). Depending on the particular qmgr and application in question and how critical it is, we may use any one of the following: Veritas clustering Two qmgrs with client channel tables Simply create a new qmgr on another box and reload the definitions It all depends (Don't you hate it when people respond with that?) Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Good thing YOU have the headache, not me! Actually we have hardware clustering already established - the HP High Availability stuff, and we test it every month. The test server(cluster) is in a different location. I initially installed MQ with clustering, but took it out when I had a problem that required a PTF that was only a month old. Too "bleeding edge" for my taste. And it turned out that our development situation got a bit crazy, and on an almost daily basis I was rewiring my channels so the MF test system was sending message to the Unix test server, then production to training, then test to trainingyou get the picture I couldn't have done it with clustering. And we do not store any data on the queues for more than 30 secondsThe only reason for a regular copy is to pick up any changes I make to MQ objects. Bill -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Speaking of which.Why wouldn't you consider CLUSTERING. It would make things simple for you. You would have automatic failover. Another secenario would be to use some sort of Hardware/Software clustering. I have been in installations whee Veratas was used. It worked well and you can (maybe) forget about the clustering. Unfortunatly you have to invest in the technology on a hardwar, software and education level. But it can be used for other critical application other than MQ. You did not mention how people are connecting to the QMGR in question. If it is client you have a channle table failover option and can have the queue manager runing on the other box to accept the work. Not much change necessary there. You mentioned that you would copy the environment over at night. WHY Are applications in your group using the QMGR as a storage device or is it a business req. If you think about it. In any good MQ environment the messages should only stay on the queues long enough to get them out the door. Otherwise yo
Re: Disaster Recovery scenario for Unix box?
Bill, if the only reason you're dong the backups nightly is to be sure you have the required object definitions, then why don't you just plan to create a new qmgr with the correct name and reload the objects/security stuff from the definitions? You can back those up using the saveqmgr SupportPac and the amqoamd command (OK, I may have that last one wrong since I did it from memory and I'm too tired/lazy to go look it up -- but it's at least close). Depending on the particular qmgr and application in question and how critical it is, we may use any one of the following: Veritas clustering Two qmgrs with client channel tables Simply create a new qmgr on another box and reload the definitions It all depends (Don't you hate it when people respond with that?) Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:50 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Good thing YOU have the headache, not me! Actually we have hardware clustering already established - the HP High Availability stuff, and we test it every month. The test server(cluster) is in a different location. I initially installed MQ with clustering, but took it out when I had a problem that required a PTF that was only a month old. Too "bleeding edge" for my taste. And it turned out that our development situation got a bit crazy, and on an almost daily basis I was rewiring my channels so the MF test system was sending message to the Unix test server, then production to training, then test to trainingyou get the picture I couldn't have done it with clustering. And we do not store any data on the queues for more than 30 secondsThe only reason for a regular copy is to pick up any changes I make to MQ objects. Bill -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:21 PM To: [EMAIL PROTECTED] Subject: Re: Disaster Recovery scenario for Unix box? Speaking of which.Why wouldn't you consider CLUSTERING. It would make things simple for you. You would have automatic failover. Another secenario would be to use some sort of Hardware/Software clustering. I have been in installations whee Veratas was used. It worked well and you can (maybe) forget about the clustering. Unfortunatly you have to invest in the technology on a hardwar, software and education level. But it can be used for other critical application other than MQ. You did not mention how people are connecting to the QMGR in question. If it is client you have a channle table failover option and can have the queue manager runing on the other box to accept the work. Not much change necessary there. You mentioned that you would copy the environment over at night. WHY Are applications in your group using the QMGR as a storage device or is it a business req. If you think about it. In any good MQ environment the messages should only stay on the queues long enough to get them out the door. Otherwise you have an issue. Restoring a QMGR from an image from a couple of hours (?) ago would imply the QMGR is stale or out of sync. You may have to consider the re-processng of old messages. This could be as devastating as loosing messages. As you can see this discussion can get very complicated. There I go...I went and gave myself a headache! my two cents bobbee >From: Rick Tsujimoto <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Disaster Recovery scenario for Unix box? >Date: Thu, 25 Sep 2003 11:59:54 -0400 > >Bill, > >One approach is to define the qmgr with the same name and leave it dormant >until needed. When a disaster hits, have the DNS updated to point to the >backup server. Once that's done, you can connect from the m/f (although, >the channels will have to be resynch'd). > >If you don't use DNS on the m/f, just update IP address in your sdr >channel. > > > > > "Beinert, > William" To: >[EMAIL PROTECTED] > <[EMAIL PROTECTED] cc: > COM> Subject: Disaster Recovery >scenario for Unix box? > Sent by: > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 09/25/2003 11:39 > AM > Please respond > to MQSeries List > > > > > >Our initial scenario for DR is the loss of the HP box that hosts both the >queue manager and the application. We have another server that provides >test and training systems. > >One approach would be to copy /var/mqm/qmgrs/ProdQM on the active server >over to /var/mqm/qmgrs/ProdQM on the stan
Re: Analyzing the log
Count me in, too! This is a good tool for those times when you need to be able to replay stuff Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Art Schanz [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 11:34 AM To: [EMAIL PROTECTED] Subject: Re: Analyzing the log Frank, As we are also at V5.3 on z/OS, I will raise my hand to join those that are looking for continued support of MO12. Hopefully, there are few more of us "BIBs" out there to persuade the author to update this SupportPac. I'll keep my fingers crossed. Cheers, Art PS - "BIBs" are Big Iron Bigots! Although, z/OS machines might not be considered "Big Iron" any more! Arthur C. Schanz Operating Systems Programmer I. - Specialist Federal Reserve Information Technology Distributed Systems Engineering IBM Certified System Administrator - WebSphere MQ V5.3 IBM Certified Solution Designer - WebSphere MQ V5.3 [EMAIL PROTECTED] "Bright, Frank" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/18/2003 10:08 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Analyzing the log I thought the MO12, MQSeries for OS/390 - Log extract program, was going to be updated to support V5.3. However, Category 2 SupportPacs are provide AS-IS with no guarantee for future support or service. URL: http://www-3.ibm.com/software/integration/support/supportpacs/individual/mo1 2.html I had sent a note using the SupportPac interface under the Support section to ask the author about MO12 future support of V5.3 but no response was received. From my experience, I believe this to be a good tool that deserves full IBM support. I am sorry to see it lagging behind and possibly being discontinued. So, there are at least two of us who are interested in it continuing as a viable tool. Is there anyone else who might want to replay persistent messages out of their MQ logs? I don't think there would be too many people who would turn this down as an option. Unfortunately, I am unaware of any other method to replay messages out of the MQ logs. Thanks Frank -Original Message- From: Rechsteiner, Guido [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 7:22 AM To: [EMAIL PROTECTED] Subject: Analyzing the log Hi I'm still looking for a way to be able to reconstruct a message from the system log og our 5.3 MQ on OS/390. Is some where the source of MQ provided CSQ1LOGP available ? Or a DSECT for the log ? Or does some body have a similar program already written (asm, cobol ?) ? If all the above isnt true, are there third party products available ? At what price ? Thanks and regards Guido The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. exfe 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 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. 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 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 n
Re: New to MQSeries
Hi, Petrou, and welcome to the MQ listserv! Well, I'm not a VSE person, but I do recognize an S0C7 abend. But perhaps I'm not saying something you don't already know. If so, I apologize. An S0C7 is usually caused when a field that's supposed to be packed decimal is used as a nonpacked field OR when a field containing nonpacked data is used an a packed decimal instruction. The classic case would be if a field that's binary integer is used in a ZAP (Zero and Add Packed) instruction. S0C7s are almost invariably (I'd have said invariably, but someone would probably come up with some exception to prove otherwise) caused by a data problem. The addition of MQSeries into this mix should make no difference. You attack this abend the same way you would any other CICS abend. Find out what's at offset +77DC into MQPSEND and then take a look at the data fields involved, either as input or output. If it's when you're doing stuff with MQ-relaed fields in the message headers, then check the required data types in the Application Reference. Good luck -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Panayiotis Petrou [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 4:16 AM To: [EMAIL PROTECTED] Subject: New to MQSeries Hi Listers, I was recently given the task of installing MQSeries version 2.1 on a VSE/ESA 2.5 running CICS TS 1.1.1. After installing MQSeries and applying a number of PTF's provided by IBM, and setting up our CICS regions, I was able to succesfully setup some local queues and run some of the sample programs/transactions (TST2) that IBM supplies. As second test we setup a connection between to CICS regions (LU 6.2) and setup all the appropriate queues and channels to attempt to send a message from one CICS region to another using the transaction TST2 PUT 01 xxx where x is the transmission queue we setup. Although the TST2 transaction completes succesfully, when MQPSEND is started to send the message to the connected system, it abends and the following messages display on the system console: C1 0121 DFHSR0001 TESTCICS An abend (code 0C7/AKEA) has occurred at offset X'77DC' in program MQPSEND . C1 0121 DFHME0116 TESTCICS (Module:DFHMEME) CICS symptom string for message DFHSR0001 is PIDS/564805400 LVLS/411 MS/DFHSR0001 RIDS/DFHSRP PTFS/VSE411 AB/S00C7 AB/UAKEA RIDS/MQPSEND ADRS/77DC. C1 0121 DFHME0116 TESTCICS (Module:DFHMEME) CICS symptom string for message DFHSR0001 is PIDS/564805400 LVLS/411 MS/DFHSR0001 RIDS/DFHSRP PTFS/VSE411 AB/S00C7 AB/UAKEA RIDS/MQPSEND ADRS/77DC. C1 0121 DFHDU0205 TESTCICS A SYSTEM DUMP FOR DUMPCODE: SR0001 , WAS SUPPRESSED BY THE DUMP TABLE OPTION FOR THIS DUMPCODE C1 0121 DFHSR0001 TESTCICS An abend (code 0C7/AKEA) has occurred at offset X'77DC' in program MQPSEND . C1 0121 DFHME0116 TESTCICS (Module:DFHMEME) CICS symptom string for message DFHSR0001 is PIDS/564805400 LVLS/411 MS/DFHSR0001 RIDS/DFHSRP PTFS/VSE411 AB/S00C7 AB/UAKEA RIDS/MQPSEND ADRS/77DC. C1 0121 DFHDU0205 TESTCICS A SYSTEM DUMP FOR DUMPCODE: SR0001 , WAS SUPPRESSED BY THE DUMP TABLE OPTION FOR THIS DUMPCODE Any help would be appreciated. Panayiotis (Pete) Petrou Systems Support Group Information Technology Division Bank Of Cyprus Ltd 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 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: Queue full question
I'm afraid not - There's no magic automatic clean up of expired messages. Getting rid of them involves some sort of attempted MQGET. On distributed platforms, you can just browse the queue and they'll disappear. On OS/390 or zOS, I belivee if you're running V5.3 (I'm not), you can set a task up that will take care of this; with older releases, you'll need to actually try to MQGET (not browse) the messages for them to go away. . Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 10:04 AM To: [EMAIL PROTECTED] Subject: Re: Queue full question Thanks Rebecca! It is a local queue scenario. If the MQPUTting application set an expiration time on the messages put to the local queue, it will cause expired messages to be removed automatically? Teresa "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> wrote: Teresa, you didn't say whether the full queue was a local one or a remote one. For a local queue, the MQPUTting application will get back a "queue full" reason code. At that point, it should do whtever it needs to do. For a remote queue, your MQPUTting application isn't going to be able to tell (unless things go REALLY awry). In this case, your PUTting app is really writing to the transmission queue. When the message gets to the other queue mangare and finds the app queue full, it will put the message on the remote qmgr's dead letter queue. If that fills up, too, then the channel between the two qmgrs will go into "PAUSED" status and message traffic will stop (ALL traffic, not just the one app). At this point, the transmission queue will start to accumulate messages. I guess (but haven't seen this one) that if it, too, were to fill up then the MQPUTting app would get back a bad reason code. No, there's no magic cleanup of the older messages. You could move them yourself to a flat file and then reload them. Or move them to another queue. I believe that one of the SupportPacs (not sure of the number, it may be MA01, but it's the one with the "q' program). If the messages have expiration times, then you should do something to cause them to go away. On the distributed qmgrs, a simply browse of the queue (as in amqsbcg) will do it. On a MF, the approach depends on the version you have, but if I remember correctly, you run a distributed qmgr. HTH -- Rebecca . Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 9:10 AM To: [EMAIL PROTECTED] Subject: Queue full question I am placing non-persistant messages to a queue for another program B to pick up, In cases where program B is down and queue becomes full, will the new message be dropped at that point or the old ones in the queue be removed by queue manager? Does anyone has C++ programming sample in how to detect queue full event? Thanks, Teresa Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software ** 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! SiteBuilder - Free, easy-to-use web site design software ** 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: MQSeries on OS/390 performance tuning
Title: Message Peter, look in the SupportPacs. There's one for MF perfromance, but I don't know the number Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Peter Moir [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 9:04 AM To: [EMAIL PROTECTED] Subject: MQSeries on OS/390 performance tuning Does anyone know of any decent documentation on performance tuning or capacity planning for MQSeries on the mainframe other than whats in the regular manuals ? Our MQ series (v5.2) queue managers on OS/390 have to date been handling relatively low volumes of small messages. Soon the message rate and message sizes going through these queue managers will increase several fold, so I need to do a bit of a health check. thanks, Pete Bank of America, UK. _ 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. _ ** 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: Queue full question
Teresa, you didn't say whether the full queue was a local one or a remote one. For a local queue, the MQPUTting application will get back a "queue full" reason code. At that point, it should do whtever it needs to do. For a remote queue, your MQPUTting application isn't going to be able to tell (unless things go REALLY awry). In this case, your PUTting app is really writing to the transmission queue. When the message gets to the other queue mangare and finds the app queue full, it will put the message on the remote qmgr's dead letter queue. If that fills up, too, then the channel between the two qmgrs will go into "PAUSED" status and message traffic will stop (ALL traffic, not just the one app). At this point, the transmission queue will start to accumulate messages. I guess (but haven't seen this one) that if it, too, were to fill up then the MQPUTting app would get back a bad reason code. No, there's no magic cleanup of the older messages. You could move them yourself to a flat file and then reload them. Or move them to another queue. I believe that one of the SupportPacs (not sure of the number, it may be MA01, but it's the one with the "q' program). If the messages have expiration times, then you should do something to cause them to go away. On the distributed qmgrs, a simply browse of the queue (as in amqsbcg) will do it. On a MF, the approach depends on the version you have, but if I remember correctly, you run a distributed qmgr. HTH -- Rebecca . Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 9:10 AM To: [EMAIL PROTECTED] Subject: Queue full question I am placing non-persistant messages to a queue for another program B to pick up, In cases where program B is down and queue becomes full, will the new message be dropped at that point or the old ones in the queue be removed by queue manager? Does anyone has C++ programming sample in how to detect queue full event? Thanks, Teresa Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software ** 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: Packed Decimal Positive Code- CWF properties in WMQI
Actually, the Fs are usually considered to be positive, but strictly speaking aren't necessarily. It all depends on how strict what's reading the data is. That's why the Cobol compilers have the semiweird NUMPROC option, so you can set for your Cobol program how strict you want to be. I suspect that Neil's right and you need to specifically tell RPG that the field is signed. But, like him. I know nothing about RPG. Isn't the innards of data representation fun?? Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 11, 2003 7:17 AM To: [EMAIL PROTECTED] Subject: Re: Packed Decimal Positive Code- CWF properties in WMQI Neil, Isn't a PD value of '123F' considered to be positive by default and will not cause an error as it is an acceptable value for the sign of a PD field? bb >From: Neil Casey <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Packed Decimal Positive Code- CWF properties in WMQI >Date: Thu, 11 Sep 2003 15:34:56 +1000 > >Hi Juni, > >This is internal magic done by Binary Coded Decimal (BCD). It is usually >second nature to mainframe programmers because it is related directly to >EBCDIC (Extended Binary Coded Decimal Interchange Code). EBCDIC is used >internally by IBM zOS (zSeries) and OS400 (iSeries) systems. > >EBCDIC numbers are internally represented as byte values x'F0', x'F1', >x'F2'...x'F9'. > >The F half-bytes are called zone fields, and number portion comes second. > >So, 1234 is represented in EBCDIC as x'F1F2F3F4'. > >Packed Decimal compresses this 'zoned decimal' value by removing the >redundant zone fields. This would be trivial, and would convert the EBCDIC >to BCD, except for the wierd way that was chosen to represent signs in >zoned decimal numbers. (A BCD representation would be x'1234' :: note there >is no sign in BCD). > >Signs are stored in EBCDIC numbers by using special zone values in the LAST >byte of a number. F means unsigned, C means positive, and D means negative. > >So, +1234 is represented as x'F1F2F3C4' and -1234 is x'F1F2F3D4'. Our >original example is unsigned. If you get a storage dump of these fields in >EBCDIC, the last digits of signed numbers end up looking like letters, >because C1=A, C2=B..C9=I, and D1=J, D2=K...D9=R, so a character dump of a >zoned field containing -1234 prints as 123M (note the upper case M, hex >value D4). > >Back to Packed decimal. > >Packed decimal is formed by taking the zoned decimal number, removing the >zone fields except for the last one, and putting the last zone at the end >of the data (and padding with zeros at the left to a byte boundary). > >Back to our value of +1234. In EBCDIC, it is x'F1F2F3C4'. In packed >decimal, this is x'01234C' and can be stored in 3 bytes instead of 4 (this >is the 'packing'). Note that a leading 0 is added to pad at the left end >out to a byte boundary. > >-1234 would be x'01234D' > >So what you are seeing is an 'unsigned' number, rather than a positive >signed number. In COBOL, it is very easy to create these values incorrectly >by declaring your data as unsigned. > >I don't know RPG, but I suspect that you need to declare a sign on the 4P2 >value (should this by -4P2?). The RPG compiler will then generate code to >create a sign zone. This is certainly the case on a zOS system with COBOL. >It sounds like WMQI might be very strict in the way it interprets the sign >value, and doesn't understand the 'unsigned' meaning of an 'F' zone. > >I have no doubt that the esoteric history of Packed Decimal numbers is of >little interest to anyone, but Juni did (sort of) ask. > >Regards, > >Neil Casey. > > >|-+> >| | Juni Per | >| | <[EMAIL PROTECTED]| >| | OO.COM> | >| | Sent by: MQSeries| >| | List | >| | <[EMAIL PROTECTED]| >| | n.AC.AT> | >| || >| || >| | 11/09/2003 14:53 | >| | Please respond to| >| | MQSeries List| >| || >|-+> > > >--- ---| > | > | > | To: [EMAIL PROTECTED] > | > | cc: > | > | Subject: Packed Decimal Positive Code- CWF properties in WMQI > | > > >--- -
Re: Hostnames or IP addresses for channel connection names
Kulbir - I'd vote for Hostnames because it allows you to change the IP address without needing to go in and change potentially a host (no pun intended) of definitions. Also, I think it's more descriptive (sort of like they used to say that Cobol was self-documenting). That said, be aware that this can (and has!) caused problems if the hostname propagation hasn't gotten to where it needs to get to before you try to connect. Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Kulbir S. Thind [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 6:07 AM To: [EMAIL PROTECTED] Subject: Hostnames or IP addresses for channel connection names Hi there, We have a very large network of MQSeries installations (> 300 installations) that are currently using a mixture of Hostnames and IP addresses for the channel connection names. We are in the process of reviewing our configurations and will be looking to standardise the use of the conname attribute, either go with Hostnames or IP addresses. Our gut feeling is to go with Hostnames as they are more descriptive of what the channel is connected to and also gives us the flexibility of being able to change IP addresses of machines without effecting channel definitions. However, there are people in our team that seem to suggest that using an IP address rather than a hostname would significantly improve performance, is this true? I can believe that there may be a difference in channel startup times but after that there should be no difference, is this correct? Which do people tend to use and why? Thanks, Kulbir. ** 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: Querying a remote queue for depth
Jerry, I've never actually done this, but theoretically, you could write a display qlocal curdepth command to the command queue on the Solaris box and then parse out the response. Maybe someone has something they've actually coded, but this might get you started. Best of luck -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Jerry Cergol [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 09, 2003 9:21 AM To: [EMAIL PROTECTED] Subject: Querying a remote queue for depth Hello, ALL! I run WMQ 5.3 on my z/OS 1.2 IBM Mainframe and I send messages to WMQ 5.3 on a Solaris 9 Sun system. Does anyone know if there's a way for me to programmatically query a queue for queue-depth on the Solaris MQ from my z/OS MQ? Thanks in advance! Jerry Cergol IBM Mainframe Operating System Support Cleveland Clinic Foundation - "Rated best in Cardiology in the USA by US News & World Report" -- Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you. Visit us online at our award-winning www.clevelandclinic.org for a complete listing of Cleveland Clinic services, staff and locations from one of the country's leading hospitals. == 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 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: OS390 source code
Bobbee -- Nope, not that one, but the sample Cobol program CSQ4BVJ1 (where do they come with these names?) will print out long messages (up to 64K). It doesn't do conversion, but that's a very minor/easy change to make (I did). Or -- Does this message not have MQSTR set? -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: OS390 source code I found a nifty program supplied in the IBM libraries named MQIGETDA. It obviously gets mesages off a queue. Nice thing is that it PRINTS them!!! Any where you want. It is controlled by a parameter file. The messages I have on the queue are in ANSII and I am printing the messages on he OS390. There doesn't seem to be a parameter in the input configuration filr to control this. Has anyone used this module and knows where the source is?? I am currently looking but maybe someone can save me some time. bobbee _ Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es 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 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: MO71 Queue Statistics...
Well, it IS called "RESET QSTATS". But seriously, this can be a real problem in that someone can inadvertently issue this command and throw off stats you've been collecting. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 8:57 AM To: [EMAIL PROTECTED] Subject: Re: MO71 Queue Statistics... Thank you all for replying... The behavior is rather strange. Does anyone know why the WMQ Design resets the stats after they've been listed ? mikhail malamud <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .NET>cc: Sent by: MQSeriesSubject: Re: MO71 Queue Statistics... List <[EMAIL PROTECTED] n.AC.AT> 09/04/2003 08:09 PM Please respond to MQSeries List I believe it would also be reset if the performance event for that particular object had occured. - Original Message - From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 04, 2003 4:33 PM Subject: Re: MO71 Queue Statistics... | You can't. Queue statistics operate according to the laws quantum physics | in which the act of taking a measurement affects the object being measured. | The rest of MQ seems to operate under Newtonian physics, thankfully. | | From the PCF Manual: | | The Reset Queue Statistics (MQCMD_RESET_Q_STATS) command reports the | performance data for a queue and then resets the performance data. | | Performance data is maintained for each local queue (including transmission | queues). It is reset at the following times: | | * When a Reset Queue Statistics command is issued | * When the queue manager is restarted | | | There is no "Inquire Queue Statistics" command. | -- T.Rob | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] | Sent: Thursday, September 04, 2003 4:00 PM | To: [EMAIL PROTECTED] | Subject: MO71 Queue Statistics... | | | Paul & All ! | | | After requesting the Queue Stats, if I cancel and re-display the INPUT | stats have been reset when I haven't requested a reset. Am I missing | something ? | | | I have the initial-refreash turned on. The point is, if I want to just | look at the stats without resetting them. How do I accomplish this ? | | | I'm using 5.3 CSD#4 with the March '03 version of mqmontp.exe. | | | Thanks, | | | Phil | | | This communication is for informational purposes only. It is not intended | as | an offer or solicitation for the purchase or sale of any financial | instrument | or as an official confirmation of any transaction. All market prices, data | and other information are not warranted as to completeness or accuracy and | are subject to change without notice. Any comments or statements made herein | do not necessarily reflect those of J.P. Morgan Chase & Co., its | subsidiaries and affiliates. | | 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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 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
Re: Accessing mainframe Qmgr from windows
Two more to try (for free!) -- Roger LaCroix's MQ VisualEdit. Nice, but be aware that it's a beta and will run out, so you might not want to distribute it too widely to end user types. Here's a URL: http://www.capitalware.biz/beta.html CommerceQuest Queue Tool. Here's a URL: http://www.commercequest.com/queuetoollogin01.asp I would agree with the others -- MO71 is a great tool, but I hesitated to distribute it to the programming staff here. (Yes, before someone all jumps all over me, I know that you can set up security to allow only browsing, but hesitated anyway. What can I say?) If you're looking for yourself, however, then by all means try MO71. There are some other SupportPacs that also do a nice job, so you might want to look at them, too. Take a look at WatchQ (MS0H) and at IH03. HTH, Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: John Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 11:49 AM To: [EMAIL PROTECTED] Subject: Re: Accessing mainframe Qmgr from windows Try the MO71 supportpac. -Original Message- From: Vivekananda Doraswamy [mailto:[EMAIL PROTECTED] Sent: 04 September 2003 14:17 To: [EMAIL PROTECTED] Subject: Accessing mainframe Qmgr from windows Hello all, I am looking for the some tool which can browse the Qmgr objects on a mainframe from Windows system. thanks vivek 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 intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ** 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 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: MQ Startup
Good morning, Larry -- Well, we don't have quite the same situation; we just let the messages accumulate during the relatively short times that IDMS (which services MOST of our queues) is down. But here are a couple of things you could try: 1) Use your automation package to look for the "CICS IS UP" message (You know, the DFHSI1517 CICS Control is being given to CICS. message) and start MQ up then. Or maybe it would be better to wait for the messages that come out when the CICS/MQ interface starts. 2) You could write a PLT program that submits something to start up MQ. 3) Not very fancy, but if it normally takes 10 minutes to start up your CICS region, just add a step at the front to submit something that waits 10 minutes and then starts up MQ (or ignore the wait, figuring not that much would accumulate in the 10 minutes). And I assume that much the same techniques could be used at CICS shutdown to stop MQ. But -- How will all your applications react when they try to connect to MQ and find it down for a longer length of time than they are used to? Sometimes things/users don't react will to changes like that. Just something to consider. Best regards, Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Larry Murray [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 02, 2003 7:37 AM To: [EMAIL PROTECTED] Subject: MQ Startup Good Morning, MQ at our shop is serviced exclusivley by CICS. If CICS is not up, messages just fill up the queues and sit there. The application servers that are sending the messages are expecting reply messages in less than a minute, or the original request is considered lost. Sowith CICS down (on each LPAR there are multiple CICS regions.) MQ is just a large repository of useless data, spending a lot of cycles to manage junk. At IPL time, MQ is started by SA/390. CICS is not started automatically. The operators start it according to some schedule that varies from IPL to IPL. I am looking for ideas, from folks in a similar situation, to getting MQ started after an IPL. Something automatedto avoid human interference...that will know when all the required prod CICS regions are available. ThanksLarry Larry Murray Putnam Investments Tech Services 1-617-760-3270 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 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: 2035 Error
I think this depends on the version of MQ. On older ones, I believe that a recycle is required (unless, maybe, it's an addition, not a change). On newer ones, I think the REFRESH SECURITY will do the trick. -- rab -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 7:33 AM To: [EMAIL PROTECTED] Subject: Re: 2035 Error Dave, Isn't the refresh to pick up OS related changes??? The QMGR security changes are picked up automatically??? / bb >From: "David C. Partridge" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: 2035 Error >Date: Thu, 28 Aug 2003 10:39:01 +0100 > >Try a REFRESH SECURITY, this should avoid the need to re-cycle the QM. > >Dave > >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 _ MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup 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 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: MA12 Batch triggering
Peter, I don't use MA12 and we're not a JES3 shop, but was it working before
you shut it down? Could it be that a different userid is now associated with
it, and that userid is causing it to fail in the SMF exit? I'd talk to the
SMF exit person and see what would trigger a failure and take it from there.
-- Rebecca
-Original Message-
From: Hill, Dave [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 3:07 PM
To: [EMAIL PROTECTED]
Subject: Re: MA12 Batch triggering
Peter -
Process name and content
EMAIL.SMTP.MSGS
USED TO PROCESS MAINFRAME EMAI
TO USERS IN
MVS
//*S010EXE EXEC PGM=MQMAIL
//EMAIL DD SYSOUT=(Q,SMTP)
//SYSOUT DD SYSOUT=*
//UTLITYF DD DUMMY
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2003 2:45 PM
To: [EMAIL PROTECTED]
Subject: MA12 Batch triggering
The trigger monitor is up and running. I can send the shutdown message to it
via CKTIEND and it shuts down as expected. So I start it back up and try to
drop a message into the triggered queue. The triggered queue name is
MQT1.LOCAL.QUEUE and the process definition is named MQT1.LOCAL.QUEUE as
well.
The problem is, the JCL it produces upon recieving a trigger message fails.
I suspect because my process definition is incorrect?
The JCL I would like to kick off is in @TSMT00.MQ.CNTL(MQEX702B). Here are
the first few lines of it:
01,//MQEX702B PROC
02,//**
03,//** THIS JCL WILL EXECUTE RN0722PC, WHICH CALLS RN0702PP, THE MQ *
04,//** WRAPPER FOR BATCH PROCESSING. *
05,//** IT ASSUMES THAT THE MA12 SUPPORT PAC WILL BE TRIGGERING IT*
06,//** THAT IS WHY THERE IS NO JOBCARD AT THE TOP. MA12 MAKES THE CARD
07,//**
08,//RN072201 EXEC PGM=DFSRRC00,REGION=9000K,
09,// PARM=(DLI,DSNMTV01,RF0001P1)
10,//STEPLIB DD DSN=SYS1.SCSQANLE,DISP=SHR
Here is the process def. (I have tried about 800 different variations, this
is the latest):
DEF PROCESS(MQT1.LOCAL.QUEUE)
APPLICID('//BTACLIB JCLLIB [EMAIL PROTECTED]')
USERDATA('//S1 EXEC PROC=MQEX702B)
APPLTYPE('z/OS')
Here is the output of the job as it fails bb interpretor:
//J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906', *
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
//BTACLIB JCLLIB [EMAIL PROTECTED]
//S1 EXEC PROC=MQEX702B
/*EOF
1 //J7900027 JOB J7211ZZRJB12345678,'P PPOTKAY X77906',
// MSGLEVEL=1,MSGCLASS=H,[EMAIL PROTECTED]
//*MAIN CLASS=DB2A
//*MAIN SYSTEM=ST1
//*
//* JOB SUBMITTED BY CKTIBAT.
//* PROCESS: MQT1.LOCAL.QUEUE
//* TRIGGERING Q: MQT1.LOCAL.QUEUE
2 //BTACLIB JCLLIB [EMAIL PROTECTED]
3 //S1 EXEC PROC=MQEX702B
IEFC025I INSTALLATION MODIFIED JCL - // JOBCARD
ERROR-5 **
and the error messages
STMT NO. MESSAGE
3 IEFC042I JOB CANCELLED BY INSTALLATION EXIT - IEFUJV
3 IEFC029I EXIT ERROR: IEFUJV ATTEMPTED TO INSERT JCL COMMENTS -
STATEM
3 IEFC607I JOB HAS NO STEPS
Peter Potkay
MQSeries Specialist
The Hartford Financial Services
[EMAIL PROTECTED]
x77906
IBM MQSeries Certified
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all
copies.
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
**
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.arch
Re: Hardware Clustering Considerations
Tom, not with AIX, no, but we had a Veritas cluster set up recently with Sun Solaris systems. Veritas now provides an agent for that environment (for MQ V5.3); this is in addition to the SupportPac Veritas cluster stuff. Don't know if this helps (and I'm certainly not Unix expert by any stretch of the imagination, so there's not a whole lot more I can provide). Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Tom Fox [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 2:24 PM To: [EMAIL PROTECTED] Subject: Hardware Clustering Considerations Does anyone have experience with MQ with Veritas clustering on IBM/AIX hardware, specifically? Any positive/negative observations? Any pointers to Veritas versus HACMP for IBM equipment and MQ? Hope this makes sense. Any help/pointers are appreciated. Regards, -tom fox Wachovia IT 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 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: message CSQX558E - too many channels?
Good luck, Ernest. One thing you might look into is using event monitoring.
I believe that an event is generated when a channel starts and stops.
Perhaps this will provide some useful information. -- Rebecca
Rebecca Bullock
Computer Sciences Corporation
MFCoE
Princeton, NJ 08541
email: [EMAIL PROTECTED] / [EMAIL PROTECTED]
-Original Message-
From: EARmerc Roberts [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 2:06 PM
To: [EMAIL PROTECTED]
Subject: Re: message CSQX558E - too many channels?
Thanx, Rebecca.
I understand what you're saying. Since several channels on my system are
consistently active, I have seen dynamic channels on the systems that
connect to mine and I assume that I may have dynamic channels created for
some or all of that activity. But I can still say unequivocally that given
the numbers we produce in my environment, I can't see us reaching 200
channels in use. What I plan to do is monitor the traffic more closely. I
will also be checking the logs more closely for other messages which might
provide more information.
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
- Forwarded by Ernest Roberts/171/DCAG/DCX on 08/25/2003 01:58 PM -
"Bullock,
Rebecca (CSC)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
G> Subject: Re: message CSQX558E
- too many channels?
Sent by:
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
08/24/2003 01:19
PM
Please respond
to MQSeries List
Ernest, you may have less than 50 channels defined, but are some of them
client channels with multiple clients using them? That will bump your
active
channel count up.
Rebecca Bullock
Computer Sciences Corporation
MFCoE
Princeton, NJ 08541
email: [EMAIL PROTECTED] / [EMAIL PROTECTED]
-Original Message-
From: EARmerc Roberts [mailto:[EMAIL PROTECTED]
Sent: Friday, August 22, 2003 10:19 AM
To: [EMAIL PROTECTED]
Subject: Re: message CSQX558E - too many channels?
I have the M&C. The problem is that I have a limit of 200 channels that I
know was not even remotely approached during our peak operating periods,
yet the message shows up. The 'For example' part is useless and should have
been omitted because it is not accurate or truly specific about whatever
the actual problem was that caused the message to be generated. The useful
part is the procedure to stop and start the channel. the rest is just
guessing and has no place in a manual that is supposed to help with problem
diagnosis and resolution. I have less than 50 channels defined.
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
Three Mercedes Drive
Montvale, NJ 07345
201-573-2619
201-573-4383 fax
866-308-3782 pager
- Forwarded by Ernest Roberts/171/DCAG/DCX on 08/22/2003 10:10 AM -
"Kearns, Emile
E" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
.ZA> Subject: Re: message
CSQX558E
- too many channels?
Sent by:
MQSeries List
<[EMAIL PROTECTED]
en.AC.AT>
08/22/2003 02:02
AM
Please respond
to MQSeries List
CSQX558E csect-name Remote channel channel-name not available
Explanation: The channel channel-name at the remote queue manager is
currently stopped or is otherwise unavailable. For example, there might be
too many channels current to be able to start it.
Severity: 8
System Action: The channel does not start.
System Programmer Response: This might be a temporary situation, and the
channel will retry. If not, check the status of the channel at the remote
queue manager. If it is stopped, issue a START CHANNEL command to restart
it. If there are too many channels current, either wait for some of the
operating channels to terminate, or stop some channels manually, before
restarting the channel.
-Original Message-
From: EARmerc Roberts [mailto:[EMAIL PROTECTED]
Sent: 21 August 2003 10:00
To: [EMAIL PROTECTED]
Subject: Re: message CSQX558E - too many channels?
Thanx, Joep,
I looked and found values of 200, which should have been enough considering
our current level of activity. I am thinking that the message doc is
somewhat misleading. I am assuming that dynamic channels are included in
the specification and we are IP-only. I'll do some more research on the
problem.
again, Thanx.
Ernest Roberts
IT - Sr Sys Prog
MBUSA, LLC
__
Robert,
There are several parameters limiting the number of active channels. They
are in CSQ6CHIP
Re: message CSQX558E - too many channels?
Ernest, you may have less than 50 channels defined, but are some of them client channels with multiple clients using them? That will bump your active channel count up. Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 10:19 AM To: [EMAIL PROTECTED] Subject: Re: message CSQX558E - too many channels? I have the M&C. The problem is that I have a limit of 200 channels that I know was not even remotely approached during our peak operating periods, yet the message shows up. The 'For example' part is useless and should have been omitted because it is not accurate or truly specific about whatever the actual problem was that caused the message to be generated. The useful part is the procedure to stop and start the channel. the rest is just guessing and has no place in a manual that is supposed to help with problem diagnosis and resolution. I have less than 50 channels defined. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC Three Mercedes Drive Montvale, NJ 07345 201-573-2619 201-573-4383 fax 866-308-3782 pager - Forwarded by Ernest Roberts/171/DCAG/DCX on 08/22/2003 10:10 AM - "Kearns, Emile E" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: .ZA> Subject: Re: message CSQX558E - too many channels? Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 08/22/2003 02:02 AM Please respond to MQSeries List CSQX558E csect-name Remote channel channel-name not available Explanation: The channel channel-name at the remote queue manager is currently stopped or is otherwise unavailable. For example, there might be too many channels current to be able to start it. Severity: 8 System Action: The channel does not start. System Programmer Response: This might be a temporary situation, and the channel will retry. If not, check the status of the channel at the remote queue manager. If it is stopped, issue a START CHANNEL command to restart it. If there are too many channels current, either wait for some of the operating channels to terminate, or stop some channels manually, before restarting the channel. -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 10:00 To: [EMAIL PROTECTED] Subject: Re: message CSQX558E - too many channels? Thanx, Joep, I looked and found values of 200, which should have been enough considering our current level of activity. I am thinking that the message doc is somewhat misleading. I am assuming that dynamic channels are included in the specification and we are IP-only. I'll do some more research on the problem. again, Thanx. Ernest Roberts IT - Sr Sys Prog MBUSA, LLC __ Robert, There are several parameters limiting the number of active channels. They are in CSQ6CHIP. See sample SCSQPROC(CSQ4X4PRM). Have a look at ACTCHL, CURRCHL, LU62CHL and TCPCHL. Cheers, Joep -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: donderdag 21 augustus 2003 16:18 To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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 ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachmen
Re: UNSUBSCRIBE
Hey! New Brunswick! Hello, fellow New Jerseyite.
Some listservs send out probes that delete people if they get a bounce back.
Maybe this one does, too (although I've never gotten a message that just
said "probing"; but maybe they just delete you after x numbers of returned,
addressee unknown messages?).
If you look at the listserv manual
(http://www.lsoft.com/manuals/1.8e/user/user.pdf), it tells you how to send
an e-mail to the actual list owner. You could try that approach.
HTH, Rebecca
-Original Message-
From: Thomas Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 10:34 AM
To: [EMAIL PROTECTED]
Subject: Re: UNSUBSCRIBE
Rebecca,
How do we sign off if our email address has changed. My email address went
from [EMAIL PROTECTED] to [EMAIL PROTECTED] In order for me to post, I
signed up to the list under my new email address. Now I get two emails for
each post. I believe if I unsubscribe, I will be unsubscribing for my new
email address and not my old email address.
Thanks,
Thomas Lane
Senior Manager, Unix Development - Middleware
Pershing Technology Group
East Brunswick, NJ
Phone: 732-565-8289
"Bullock, Rebecca
(CSC)" To:
[EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
>Subject: Re: UNSUBSCRIBE
Sent by: MQSeries
List
<[EMAIL PROTECTED]
N.AC.AT>
08/21/2003 09:32
AM
Please respond to
MQSeries List
Once again
Here's what you need to do:
You may leave the list at any time by sending a "SIGNOFF MQSERIES"
command (no quotes and use this as the body of the message) to
[EMAIL PROTECTED]
Do NOT send this to [EMAIL PROTECTED]; that won't get you off this
listserv, it'll only send your wish to do so to everyone on the list.
-Original Message-
From: Kinlen, Dan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 11:12 AM
To: [EMAIL PROTECTED]
Subject: UNSUBSCRIBE
UNSUBSCRIBE
RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or
any instructions by e-mail that would require your signature. Information
contained in this communication is not considered an official record of
your
account and does not supersede normal trade confirmations or statements.
Any information provided has been prepared from sources believed to be
reliable but is not guaranteed, does not represent all available data
necessary for making investment decisions and is for informational purposes
only.
This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations. Any distribution, use or copying
of this e-mail or the information it contains by other than an intended
recipient is unauthorized. If you receive this e-mail in error, please
advise me (by return e-mail or otherwise) immediately.
Information received by or sent from this system is subject to review by
supervisory personnel, is retained and may be produced to regulatory
authorities or others with a legal right to the information.
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 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
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 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.
Instructio
Re: message CSQX558E - too many channels?
Hi, Ernest. Yes, there is a parameter that limits the number of active channels. It's in the CSQ6CHIP macro that you coded to create your XPARM for the CHIN address space. Hope this helps -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: EARmerc Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: message CSQX558E - too many channels? Hello MQ persons, We are running MQ v 5.3 on OS/390 v2.10. Our qmgr reported message CSQX558E for a channel and the M&C guide said about this: "there might be too many channels current to be able to start it." The channel appeared to have no problem after a STOP and then a START were issued. What I want to do is make sure I am not restricting our growing MQ traffic with my current parameter settings. Is there a parameter that actually limits the number of active channels? Is there a DISPLAY command that can show that parameter value? I found parameter "CTHREAD=300" in the assembly JCL for CSQ6SYSP. Also, "IDBACK=20" was specified for non-TSO connections. The doc doesn't give a clear indication of what the parameters affect, but does state that a channel initiator can have more than one connection to a qmgr. Am I on the right track with this issue? should I alter those parameters upward? Thanx in advance? Ernest Roberts IT - Sr Sys Prog MBUSA, LLC 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 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: UNSUBSCRIBE
Once again Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command (no quotes and use this as the body of the message) to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. 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 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: OS/390 JCLPUT
June, the MQGET JCL is as follows. -- My best, Rebecca
For this one, I'd very strongly suggest that you modify the GMO in the
sample source to turn on conversion on the get (unless, I guess, you're
strictly mainframe). It'll make this utility a whole lot more useful. To do
this, find the following code and make the change (Add the MQGMO-CONVERT +
line):
*
*Setup MQGMO-OPTIONS depending on parameters passed
*into program
*
COMPUTE MQGMO-OPTIONS = MQGMO-NO-WAIT +
MQGMO-CONVERT +
MQGMO-ACCEPT-TRUNCATED-MSG.
Anyway, here's the JCL:
//*
//* PROGRAM CSQ4BVJ1 ISSUES MQGET ON A QUEUE.
//* (EXEC AND PARM STATEMENTS ARE COMMENTED OUT AS SHIPPED)
//*
//* - FIRST PARM (++QMGR++) QUEUE MANAGER NAME
//* - SECOND PARM (++QUEUE++) QUEUE NAME
//* - THIRD PARM (++MSGS++) THE NUMBER OF MESSAGES TO GET-()
//* - FOURTH PARM (++GET++) GET TYPE-(B)ROWSE/(D)ESTRUCTIVE
//* - FIFTH PARM (++SYNC++) (S)YNCPOINT/(N)O SYNCPOINT
//* MESSAGES ARE PRINTED TO DD SYSPRINT
//*
//*
//GETMSGS EXEC PGM=CSQ4BVJ1,REGION=1024K,
// PARM=('QMGR,QUEUE.NAME,,D,N')
//STEPLIB DD DSN=MQSERIES.SCSQLOAD,DISP=SHR
//SYSDBOUT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSOUX DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
-Original Message-
From: June Lawton [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2003 10:06 AM
To: [EMAIL PROTECTED]
Subject: Re: OS/390 JCLPUT
Hey You!
The JCL you gave me was perfect. I PUT some messages out on a Q. Then went
into the CLIST and moved them to another Q and deleted, etc.
Now, can you help with a GET?
June Lawton
Information Systems
The PMA Insurance Group
[EMAIL PROTECTED]
(T) 610.397.5058
(F) 610.397.5311
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 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: OS/390 JCLPUT
June, are you looking for JCL for the sample program CSQ4BVK1 that you
install as part of the MQ IVPs? Here's that JCL. Or are you looking for
something else entirely? -- Rebecca
//*
//*
//* PROGRAM CSQ4BVK1 ISSUES MQPUT ON A QUEUE.
//* - FIRST PARM (++QMGR++) QUEUE MANAGER NAME
//* - SECOND PARM (++QUEUE++) QUEUE NAME
//* - THIRD PARM (++MSGS++) THE NUMBER OF MESSAGES TO PUT-()
//* - FOURTH PARM (++PAD++) THE PADDING CHARACTER
//* - FIFTH PARM (++LEN++) THE LENGTH OF EACH MESSAGE-()
//* - SIXTH PARM (++PERS++) (P)ERSISTENT/(N)ON PERSISTENT MESSAGES
//* MESSAGES ARE PRINTED TO DD SYSPRINT
//*
//*
//PUTMSGS EXEC PGM=CSQ4BVK1,
// PARM=('QMGR,QUEUE.NAME,003,R,0010,N')
//STEPLIB DD DSN=MQSERIES.SCSQAUTH,DISP=SHR
// DD DSN=MQSERIES.SCSQLOAD,DISP=SHR
//SYSDBOUT DD SYSOUT=*
//SYSABOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSOUX DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
-Original Message-
From: June Lawton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 10:27 AM
To: [EMAIL PROTECTED]
Subject: OS/390 JCLPUT
Several months ago I attended a MQ OS/390 Sysadmin class where in one of
the exercises there was JCL to launch a batch program to put messages on a
queue. Does anybody have a sample of this or something similar?
Thanks!
June Lawton
Information Systems
The PMA Insurance Group
[EMAIL PROTECTED]
(T) 610.397.5058
(F) 610.397.5311
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 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: XMITQ name
Yuval -- Yes, you can. We run several sets of channels between two qmgrs and each channel has it's own xmitq. The "extra" xmitq's are just the name of the remote qmgr with a number added on the end (MQ1.2, MQ1.3, etc), but they can be anything valid. The advantage of naming the xmitq after the remote qmgr is that it means you do not have to define a qremote when you're simply responding to a message. Saves on administration. When you are responding and move the ReplytoQmgr name into the message descriptor, MQ will look for a qlocal with that name, assuming the qmgr name isn't the local qmgr. It saves going through the qremote name resolution process AND it means that your application will respond to whichever qmgr my have sent the query. -Original Message- From: Yuval Ofer [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 10:32 AM To: [EMAIL PROTECTED] Subject: XMITQ name The manual recommends that the name of the XMIT queue will be the same as the name of the remote queue manager. Is that a MUST? (That is can I use the XMIT-Q name as a 'pointer')? Or did any of you see any site that uses other names for the XMIT queues? (e.g. can you configure channels between two queue manager, each with a different xmit queue name?) -- Yuval Ofer mailto:[EMAIL PROTECTED] #include 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 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: Local Queue Reaches Maximum Depth
Hi, Carl. I just thought I'd weigh in here with a place to find more current doc (not that I think it'll make any difference for your issue). The starting point for MQ is http://www-3.ibm.com/software/integration/wmq/ Follow the link to "Library" to find manuals. (or use http://www-3.ibm.com/software/integration/mqfamily/library/manualsa/ and avoid the confusing menus) You and Ronald are both right -- the (obvious) thing for the application to have done was to either just discard the bad message or, better, to have moved it elsewhere so it could be looked at and its source determined. But, if your programmers are anything like ours, you may have a long wait for that to happen (as in "well, it only happened this once and we're very busy") When Ronald talks about an alert mechanism, I think he's referring to MQ Events. There's a whole manual for this -- Event Monitoring. You want Queue Depth Events, and specifically Queue Depth High. You'll need to turn on Performance Events for the queue manager (check -- it might already be on). And you'll also need to enable the event on the qlocal definition and then set the percentage deep that you want to be alerted about. The actual event will cause a message to go to the SYSTEM.ADMIN.PERFM.EVENT queue, but you'll need to write something to handle the message. Depending on what your set up is, it might be easier to simply have something set up to periodically check for the number of messages in the queue and send you an alert if the number's too high (and too high can be defined as pretty low -- I have some queues that I get a page if the depth reaches 3; acceptable qdepth is very application-specific). You might have your automation people set this up for you, or perhaps you can do something using the JES2 automatic commands ($TA) -- sorry, I don't know the equivalent JES3 commands if you're a JES3 shop. This kind of thing is easily done in Unix using a cron and a simple shell script. You could (if you have a Unix qmgr) send the depth query from the Unix qmgr to OS/390 and parse out the response and handle it that way. Anyway, I hope that this provides some help. Best regards... Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Mc Burnie, Carl [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2003 7:45 AM To: [EMAIL PROTECTED] Subject: AW: Local Queue Reaches Maximum Depth Hi Ronald, could you elaborate on the "alert mechanism" i.e. does it result in a distinct message being produced? If it does, we could "catch" the message and take appropriate action. When I said "bad" message, I meant a message that the application wasn't expecting (completely different format). It was garbage and should, in my opinion, have been disguarded by the application rather than blocking the queue. Thanks, Carl -Ursprungliche Nachricht- Von: Ronald Weinger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 5. August 2003 13:39 An: [EMAIL PROTECTED] Betreff: Re: Local Queue Reaches Maximum Depth You can get an alert generated when the queue reaches a percentage on the max depth. You have to determine what that percentage is, and it will depend on how rapidly messages are being put on the queue. And then have something that will report on it to someone who can act. It is also pretty simple to write an application that will periodically issue an inquiry on the queue depth, so you can generate your own alert at a specific depth, and continue to generate alerts as long as theat value is exceeded. What is a 'bad' message? A good application design is to discard garbage as spam. "Mc Burnie, Carl" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] RZBANK.COM> cc: Sent by: "MQSeries Subject: Local Queue Reaches Maximum Depth List" <[EMAIL PROTECTED] C.AT> 08/05/2003 01:39 AM Please respond to "MQSeries List" Hi, I'm covering WebSphere MQ for z/OS 5.3 for a few weeks and MQ isn't exactly my speciality, so please be patient!! There was a problem yesterday with a local queue that reached maximum depth and overflowed to the "dead letter queue". There was a "bad" message in the local queue and all subsequent messages stacked up behind it until maximum depth was reached and messages began overflowing into the "dead letter queue". We would like to identify this type of problem much earlier in the future and are looking for some automation ideas? 1. The MQ API doesn't seem to return a "maximum depth reached" response for the MQPUT call, is that correct? 2. When the maximum depth for a local queue is reached MQ doesn't seem to write any sort of warning message to the system log
Re: UNSUBSCRIBE
Sanjeev, those are the instructions that the listserv provided. Can't say that I've ever done it since I didn't want to leave the listserv. Anyone else out there have anything to contribute? -Original Message- From: Sanjeev [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 4:48 PM To: [EMAIL PROTECTED] Subject: Re: UNSUBSCRIBE I tried this but it didnt work:( - Original Message - From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 8:57 PM Subject: Re: UNSUBSCRIBE > Here's what you need to do: > > You may leave the list at any time by sending a "SIGNOFF MQSERIES" > command to [EMAIL PROTECTED] > > Do NOT send this to [EMAIL PROTECTED]; that won't get you off this > listserv, it'll only send your wish to do so to everyone on the list. > > > > > ** > 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 > 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 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: Reason code 2257
Chris, could you be pointing somewhere other than where you thought you were
pointing? And that whatever you were/are pointing at is now something that's
valid for the V1 header but wasn't before? Did that make sense? As you say,
h
Rebecca Bullock
Computer Sciences Corporation
MFCoE
Princeton, NJ 08541
email: [EMAIL PROTECTED] / [EMAIL PROTECTED]
-Original Message-
From: Fryett.Chris [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 6:18 PM
To: [EMAIL PROTECTED]
Subject: FW: Re: Reason code 2257
Interesting. The problem has disappeared. Hmmm.
Chris
> -Original Message-
> From: Fryett.Chris
> Sent: Tuesday, July 22, 2003 4:14 PM
> To: 'MQSeries List'
> Subject: RE: Re: Reason code 2257
>
> Stefan:
>
> I have been tracking down how the 2257 is occurring, but I'm a little
baffled. Here is a little code snippet that will always carry the MQMDE and
set the MQMD to version 1:
>
> m_pQueue.setName("MY_QUEUE");
> m_pQueue.setConnectionReference(m_Qmgr);
>
m_pQueue.setOpenOptions(MQOO_OUTPUT+MQOO_FAIL_IF_QUIESCING+MQOO_BIND_ON_OPEN
);
> ...
> // We need to add an additional header if the format type is
> // MQFMT_MD_EXTENSION. This will mean a MQMDE header is
> // added to the message package. This header is only compatable
with
> // MQMD Version 1 at this time.
> if (!memcmp (getFormat(), MQFMT_MD_EXTENSION, MQ_FORMAT_LENGTH))
> {
> m_myMessage = new MyImqMessage(m_Message);
> m_myMessage->setVersion1();
> }
> ...
> // set the put message options
> ImqPutMessageOptions pmo;
> pmo.setOptions(MQPMO_SYNCPOINT + MQPMO_FAIL_IF_QUIESCING);
> if (!memcmp (getFormat(), MQFMT_MD_EXTENSION, MQ_FORMAT_LENGTH))
> nRet = m_pQueue.put(*m_myMessage, pmo);
> else
> nRet = m_pQueue.put(m_Message, pmo);
> if (!nRet)
> cout << "Houston, we have a problem..." << endl;
> ...
>
> During some initial testing I found when I removed the MQOO_BIND_ON_OPEN
all works fine, but when I add it I get the 2257 error. Doesn't make sense.
>
> Chris
>
>
> -Original Message-
> From: Stefan Sievert [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 22, 2003 3:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Reason code 2257
>
>
> Chris,
> I am not sure if I understand your question, but doesn't the reason code
> explanation answer the 'why' of it, when it says: "An MQGET, MQPUT, or
> MQPUT1 call was issued specifying options that required an MQMD with a
> version number not less than MQMD_VERSION_2, but the MQMD supplied did not
> satisfy this condition."
> In other words, your put message options likely contain a value that
> REQUIRES a MD version 2, but you pass in a version 1 MD.
> Do you explicitly set the MD version to 1 or do you use the initalized
> structure from the header file/copy book?
> Can you supply the code snippet with the initialization and the MQPUT
call?
> Thanks,
> Stefan
>
>
> >From: "Fryett.Chris" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: Reason code 2257
> >Date: Tue, 22 Jul 2003 13:35:24 -0400
> >
> >Funny. Already know what 2257 means. Looking on reasons based on my
> >description.
> >
> >Chris
> >
> >-Original Message-
> >From: Wmq Techie [mailto:[EMAIL PROTECTED]
> >Sent: Tuesday, July 22, 2003 1:13 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Reason code 2257
> >
> >
> >MQRC_WRONG_MD_VERSION (2257)
> >
> >Explanation: An MQGET, MQPUT, or MQPUT1 call
> >was issued specifying options that required an MQMD
> >with a version number not less than
> >MQMD_VERSION_2, but the MQMD supplied did not
> >satisfy this condition.
> >
> >This reason code occurs in the following environments:
> >AIX, HP-UX, z/OS, OS/2, OS/400, Solaris, Windows,
> >plus WebSphere MQ clients connected to these systems.
> >Completion Code: MQCC_FAILED
> >
> >Programmer Response: Modify the application to pass
> >a version-2 MQMD. Check the application logic to
> >ensure that the Version field in MQMD has been set to
> >MQMD_VERSION_2. Alternatively, remove the option
> >that requires the version-2 MQMD.
> > > I am passing a Version 1 MQMD to support the lovely OS/390, but when I
> >run the
> > > same code on the distributed side with a MQOO_BIND_ON_OPEN in the open
> >options I
> > > receive a 2257 at the time I attempt to put a message to a queue.
> >Anyone have
> > > any ideas? I am also using a Version 1 MQMD on the distributed.>
> > >
> > > Chris
> > >
> > >
> > >
> > >
> > >
>
>***
*
> > > *
> > > The information transmitted is intended solely for the individual or
> >entity to
> > > which it is addressed and may contain confidential and/or privileged
> >material.
> > > Any review, retransmission, dissemination or other use of or taking
> >action in
> > > reliance
Re: MQPUT generates AMQ9208 error
Roger, a (very very very) long shot -- Could it be some combination of stuff in the message that's causing a communications glitch? Or that the particular system they're sending to can't handle? Don't even know if that's possible. Or is this happening on every PUT? Do they have more than one qmgr in their mix that's running the same level on MQ? If they send the same message there, does it also fail? Could they have a channel or message exit that's failing on the message? (This last can cause some strange things) Just some thoughts...Hope it helps, although it probably won't :-( Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Roger Lacroix [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:18 PM To: [EMAIL PROTECTED] Subject: Re: MQPUT generates AMQ9208 error Hi, As I mentioned in my original posting "And the message is NOT written to the queue." later Roger... At 05:08 PM 7/22/2003, you wrote: >You forgot to mention the state of the message even though the tcp/ip error >is thrown. Does it make it without any issues??? > > > >Well, since there seems to be a tcp/ip issue here, i would go with changing >the listener port number and see if it makes any difference. Because, this >whole set up looks so basic that the error must be the underlying layer >rather than MQ, which is also proven by the fact that none of the api calls >return a bad reason code. > > > >Also since the message size is pretty small, i would think this should work >just fine. > > > >Another thing that could be tried is to keep the same listener and run >amqsputc from windows box to see what happens. > > > >Cheers > >Kumar > > > >---Original Message--- > > > >From: MQSeries List > >Date: Tuesday, July 22, 2003 04:45:35 PM > >To: [EMAIL PROTECTED] > >Subject: Re: MQPUT generates AMQ9208 error > > > >Hi, > > > >Interesting but does not give the "why". > > > >Never "assume". :) It is NOT a Sender / Receiver channel combination. > > > >Let me give more details. > >MQ Visual Edit is a Java application using MA88 > >MQ Visual Edit is running on Windows NT v4 SP6a using JRE v1.41 > >The queue manager v5.2 is on AIX v5.1 (a different box than MQ Visual Edit) > >MQ Visual Edit is connecting to a SVRCONN channel called SYSTEM.DEF.SVRCONN >on port 1414 of queue manager on AIX. > >The queue on the AIX queue manager is a local queue > >The message size is about 3KB > > > >Anybody have any ideas? > > > >Regards, > >Roger Lacroix > >Enterprise Architect > >Capitalware Inc. > > > > > >At 04:06 PM 7/22/2003, you wrote: > > > >Roger, check this link out. It may throw some more insight. > > > >http://www-1.ibm.com/support/docview.wss?uid=swg21024141 > > > >Since tcp/ip is involved i would assume a sdr=>rcvr channel is involved here >and not Svrconn as there are 2 qmgrs in picture. Try stopping and >restarting the channel. By the way, is the put being done to a remote >queue??? Is the message staying on the TQ??? Is the message way too big??? > > > >Cheers > >Kumar > > > >---Original Message--- > > > >From: MQSeries List > >Date: Tuesday, July 22, 2003 03:39:17 PM > >To: [EMAIL PROTECTED] > >Subject: MQPUT generates AMQ9208 error > > > >All: > > > >A user has report a very strange error using MQ Visual Edit. They have many >queue managers but it only happens with 1 particular queue manager (WMQ = v5 >2 AIX = v5.1). > > > >Note: MQ Visual Edit uses MA88 dated: July 25, 2002. > > > >They can Connect, Open, Get (browse), Close and Disconnect with MQ Visual >Edit without any problems. But when they try to do Connect, Open, Put, >Close and Disconnect the following is written to the log: > > > > > >07/15/03 13:21:44 > >AMQ9208: Error on receive from host 192.10.10.10. > > > >EXPLANATION: > >An error occurred receiving data from 192.10.10.10 over TCP/IP. This may be > >due to a communications failure. > > > >ACTION: > >The return code from the TCP/IP (read) call was 73 (X'49'). Record these > > >values > >and tell the systems administrator. > > > > > >The weird part is that MQ Visual Edit does NOT get any errors. The >completion code & reason code is zero for all calls (Connect, Open, Put, >Close and Disconnect). And the message is NOT written to the queue. > > > >Since my program can read (MQGET) messages, what would cause the listener >to have problems on a MQPUT? > > > >Anybody got any ideas? Attention Hursley - could this be caused by a >missing ptf or service pac? > > > >Thanks > >Roger Lacroix > >Enterprise Architect > >Capitalware Inc. > >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 availabl
Re: Queue Editing Tools
Q Tool is nice (especially for free), but I personally prefer Roger's MQEdit. The main reason I chose to recommend Q Tool to the users here over MQEdit is that you have to keep downloading new (and improved) versions of MQEdit since it's a beta product. Try them both, since both are free, and see which better meets your needs. One acid test for a queue browser debugger type package is how it handles EBCDIC data (unless you will never need to contend with EBCDIC messages). And how do they (if they do) handle an EBCDIC message if the MQFMT field is blank? After all, many programmers whose messages are staying within a mainframe environment will not set that field to MQSTR (yes, perhaps shortsighted, but they always say "well, it works"). Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Kenneth M Viney [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 6:50 PM To: [EMAIL PROTECTED] Subject: Re: Queue Editing Tools We've been trialling BPI at our site and it does all the things that we require with a minimum of fuss and easy to use. And one added bonus is that it doesn't have that extra functionality that no-one ever uses but some commercial tools seem to add in an attempt to impress. Try this one ... it's good .. and FRE!! Ken "Taylor, Neil" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 23/07/2003 01:51 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: Queue Editing Tools There is our product you could try: Commercequest BPI Q Tool. Its free and quite powerful. Just visit our website and go to the Solution Center section to gain access. I'm not aware of any other tools, apart from the IBM WSMQ Support packs. http://www.commercequest.com/ Neil -Original Message- From: Thomas, Don [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 16:15 To: [EMAIL PROTECTED] Subject: Queue Editing Tools Can anyone provide me with a list of tools available, besides the DOS based ones included with the MQ product, that allow for a user to interact with the data on a queue. Specifically I'm looking at replacing Candle's PQEdit. Don Thomas EDS - PASC * Phone: +01-412-893-1659 Fax: 412-893-1844 * mailto:[EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This message and any attachments are confidential and for the addressee only. It may be subject to legal privilege or confidentiality obligations imposed by legislation. If you have received it in error, please notify the sender and immediately delete the message without making any copy of it. The legal effect of this message is subject to its compliance with our Electronic Communication Policy and Guidelines (available at http://www.tac.vic.gov.au/ecom-policy and at http://www.taclaw.com.au/taclawecom-policy). You should consider whether this message includes a digital signature, and whether it complies with those guidelines, when deciding whether it should be relied upon. It is the policy of TAC and TAC Law that our e-mail addresses are for business use only. All e-mail sent to us may be inspected and used for any lawful purpose. Our policy prohibiting transmission of inappropriate material via e-mail is strictly enforced. ** 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: Reality check - dots in names
T.Rob, we have used dot-delimited names, too, for WAS V3.x and V4.x. No problems that I've ever heard the programmers complain about. -- Rebecca -Original Message-From: Art Schanz [mailto:[EMAIL PROTECTED]Sent: Monday, July 21, 2003 4:09 PMTo: [EMAIL PROTECTED]Subject: Re: Reality check - dots in namesRob, We've been using 'dot-delimited' names for MQ queue names for years.never had any problems. That's included WAS Versions 3.x, 4.x & V5. Sorry, I don't have any URL links at my fingertips. WAS should be able to handle any valid MQ-accepted characters, though. I think your developers are mistaken. Cheers,Arthur C. SchanzOperating Systems Programmer I. - SpecialistFederal Reserve Information TechnologyDistributed Systems EngineeringIBM Certified System Administrator - WebSphere MQ V5.3IBM Certified Solution Designer - WebSphere MQ V5.3(804) 697-3889[EMAIL PROTECTED] "Wyatt, T. Rob" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 07/21/2003 02:55 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Reality check - dots in namesOk, I need to ask your help for a reality check here! One of our projectmanagers says his developers claim they've had problems using dots inWebsphere queue names (inside of Websphere Application Server, that is) andthey insist that they need to use underscores instead. Has anyone elseheard of this problem? If so, can you provide any URL pointers?Thanks -- T.RobInstructions 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 ** 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: UNSUBSCRIBE
Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. ** 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: MQGMO-WAITINTERVAL
Teresa, you can certainly get by msgid and correlid. What will happen is that MQ will search the queue for that message. On the MF, if you index by correlid, MQ can go directly to that message without searching for it. If the queue depth is small, it doesn't make much difference, but if you have thousands of messages to look through, it can. Hope this makes it more clear Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:46 PM To: [EMAIL PROTECTED] Subject: Re: MQGMO-WAITINTERVAL One of our MQ client application is doing a MQGET based on the the correlation identifier (CorrelId) field of their reply messages so they can associate the reply with its original request. However, this has not been implemented in production yet. Both client and server apps are going to run on NT. My concern is if the queue index is available on OS/390 platform, applications on the NT side can only get messages from queue by what is the next available message in the queue? "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: Yes, it is a queue parameter available on z/OS (OS/390) only. -Original Message- From: Teresa Cheung [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:00 PM To: [EMAIL PROTECTED] Subject: Re: MQGMO-WAITINTERVAL Hi Peter, When you say "index your queue by CorrelId or Message ID", is it done by queue configuration or something else? Thanks, TC "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: If you index your queue by CorrelId or Message ID, whichever you method you use to select your messages, you will see big performance gain. We have an IMS app that does a get by CorrelID. Once, the reply queue had 3,000 orphans (don' t ask, its been fixed). Anyway, while that queue had 3,000 messages on it, the IMS performance folks were howling on all the CPU being used by MQ. I cleared out the queue and they were happy. I indexed the queue, put 10,000 dummy messages in the queue, and asked the IMS performance folks what they saw now. No CPU usage problems at all. -Original Message- From: Dave Adam [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 10:31 AM To: [EMAIL PROTECTED] Subject: Re: MQGMO-WAITINTERVAL I guess I should have included our design specs, this was a receiver only channel from NT to ZOS (I am the CICS guy not MQ) as it hit ZOS there was a trigger on the queue that would call a process that made a request to our scheduling package to submit a job to off-load the queue to a VSAM file for a daily process (and the structure of the data was that each detail line was a separate message and could consist of up to 5000 messages per entity when I started to look at this I made some suggestions, one was get the entity to a single message, which we have done now we took the wait out and no delays, but are in the process of removing the trigger and scheduling the off-load job to run a couple times a day, and as the first step of the daily process however, we have a second application, that requests thousands of jobs that do the same thing to DB2, and I was hoping to add a wait so I could cut the jobs to a handful, by keeping the off-load alive longer (none of this goes through CICS) but you mentioned orphans that increase in numbers making your process run slower and have a possibility of not meeting goals could you not write an audit trail when the request is made in CICS, so you could schedule a process that could determine if the orphan could be deleted for our SYSPlex, we use the coupling facility for Temp Storage and I run a task every 2 hours that (by queue) determines if it is still valid, and if not, I delete it, and some of the queues have up to a 24 hour lag time you are absolutely correct about the level of understanding on my part, and I can relate to your situation, but even with the lack of knowledge, I removed 90% of the definitions in our MQ system, and we now are running without calls to the help desk I'll be the first one to admit that I don't know or understand MQ, but I will also tell you I have had alot of fun redoing this environment, eliminating errors, having programmers make changes and actually see the results they expected maybe we have too simplistic an environment now, but I can't seem to find the complexity people said we had so your insight into the real-time distributed process hits home and is one I will pass on to our Architects, who I hope take ownership of MQ here Dave Adam Supervalu Home Office Project Specialist (952) 828-4736 [EMAIL PROTECTED] If one of the engines on a two engine plane fails The other engine will always get you to the site of the crash --
Re: UNSUBSCRIBE
Here's what you need to do: You may leave the list at any time by sending a "SIGNOFF MQSERIES" command to [EMAIL PROTECTED] Do NOT send this to [EMAIL PROTECTED]; that won't get you off this listserv, it'll only send your wish to do so to everyone on the list. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: UNSUBSCRIBE UNSUBSCRIBE RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. 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 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: Remote management of MQ on OS/390?
Although Bill's question would imply (maybe) that he's connecting from a qmgr on Windows. So, he should be able to use that to pass stuff along from MO71 to OS/390. -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 3:13 PM To: [EMAIL PROTECTED] Subject: Re: Remote management of MQ on OS/390? Without the Client Feature, no clients can connect to the OS/390 QMGR, MO71 will not connect either. -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:35 PM To: [EMAIL PROTECTED] Subject: Re: Remote management of MQ on OS/390? No. and don't plan to... Bill -Original Message- From: Kinlen, Dan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 12:48 PM To: [EMAIL PROTECTED] Subject: Re: Remote management of MQ on OS/390? Do you have the Client feature for OS/390 installed? -Original Message- From: Beinert, William [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 11:27 AM To: [EMAIL PROTECTED] Subject: Remote management of MQ on OS/390? I have MQ Explorer on my Win2K workstation, and I have no problems connecting to QMs on HP and Windows (versions 5.2 & 5.3 respectively). I still have 2.1 on OS/390, and I can't connect. The CMDSERV is running and the SYSTEM.ADMIN.SVRCONN channel is running. I had Security create me a RACF ID that matches my Windows ID. When I try to connect, all that happens is that the SYSTEM.ADMIN.SVRCONN channel goes active and inactive in a second. Anybody have any idea what I've missed? Or is 2.1 just too old? Bill Beinert Systems Programming Con Edison (212) 460-4853 When they took the fourth amendment, I was quiet because I didn't deal drugs! When they took the sixth amendment, I was quiet because, I was innocent. When they took the second amendment, I was quiet because I didn't own a gun! Now they've taken the first amendment, and I can say (or do) nothing about it. The Second Amendment is in place in case they ignore the others. MODWN DAbE 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 RBC Dain Rauscher does not accept buy, sell or cancel orders by e-mail, or any instructions by e-mail that would require your signature. Information contained in this communication is not considered an official record of your account and does not supersede normal trade confirmations or statements. Any information provided has been prepared from sources believed to be reliable but is not guaranteed, does not represent all available data necessary for making investment decisions and is for informational purposes only. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you receive this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Information received by or sent from this system is subject to review by supervisory personnel, is retained and may be produced to regulatory authorities or others with a legal right to the information. 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 ** 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: Message on dead letter queue
Francois -- Here's what you need to do (and it's nuts, but so be it): 1) Start with the hex reason code (2508) 2) Flip the two bytes, giving you 0825 3) Convert that to decimal, giving you 2085 It has to do with how stuff is stored internally. I have notes on this particular thing -- it's not something a sane person would remember. Cheers, Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: F Vartan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 3:41 PM To: [EMAIL PROTECTED] Subject: Message on dead letter queue Hi everyone, On the NT with WQM 5.3 when I am using amqsbcgc to browse our dead letter queue, I am getting this at the beginning of a message: : 444C 4820 0100 2508 5445 5354 'DLH %...TEST' 0010: 2E41 474D 452E 4F52 4420 2020 2020 2020 '.AGME.ORD ' 0020: 2020 2020 2020 2020 2020 2020 2020 2020 ' ' I think 2508 (decimal 9480) is the reason field. But d there is no such reason code. How to figure it out? Is this explained in any manual? Many thanks. Francois __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: Using setmqaut
Pavel, while it may seem somewhat counterintuitive, it's not terribly uncommon for a user who can change security access to something to not have access to that thing. Yes, they can change the access, but the hope is that this would be caught through some sort of reporting/logging. The other advantage of doing this is that it prevents accidental modification of some critical queue data; if you needed to do those modifications, you would at that time do the setmqaut and then turn it back off when you're done. This may not be irrelevant here anyway. Since setmqaut sets access at the group level and, I presume, you could set the permissions on setmqaut so that group could not run it while the owner could, it would be possible to stop a user in the mqm group, but is not mqm himself, from running setmqaut to reset permissions. Just my take on this issue, based on doing other security stuff that's not MQ... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: Re: Using setmqaut David, First, I seems to me I tried all those tricks while ago and found mqm is a God. Second, logically mqm is not in the ACLs from the very beginning (check with dspmqaut), so deleting him from there should not change anything (just an educated guess) Third, even assuming mqm could be deleted from .. whatever, why whould s/he be able to add him/herself back .. there.. using that very setmqaut? (another educated guess). All those considerations are valid for Unix and (if I am not mistaken) Windows. I am not sure about other platforms. Hope this will help, Pavel "David C. Partridge"To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RIMEUR.COM> Subject: Re: Using setmqaut Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 07/09/2003 10:17 AM Please respond to MQSeries List Rick, Hmmm... that sounds like it *is* possible, but use at your own risk - can anyone confirm? Thanks David 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 e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: Finding userids - OS/390
Title: Message Hi, Pete. I suspect that the answer will be "no" from IBM because they want to be able to modify the format of the log without worrying about impacting customers (at least, that was the explanation from the distributed crowd, and I'd expect the same from the MF folks). Actually, I would have expected MO12 to have done the trick since I'd expect to be able to extract the userids from the message headers. You may have to play around with it though (It's been a while since I did any significant playing with the MO12 output, so I can't say for absolute positive). Cheers, Rebecca Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Peter Moir [mailto:[EMAIL PROTECTED]Sent: Wednesday, July 09, 2003 7:07 AMTo: [EMAIL PROTECTED]Subject: Finding userids - OS/390 re: MQ v5.2 on OS/390 V2.10. Anyone know if there are macros to map the records on the MQ logs. There is some information in there that I want that I don't seem to be able to get easily by other means i.e CSQ1LOGP. In particular the userid associated with incoming messages. I get it in the detailed o/p from CSQ1LOGP (UNDO/REDO record) but not easily identifiable, the userid field on the summary o/p doesn't list these userids (I get the CHIN userid). I have MO12 but doesn't help in this case. Maybe (probably!) there's an easier way ? I want to do this over a period of time so would rather not run any traces and because of the current security settings on the systems I'm interested in these userids are not being checked by RACF so I can't find them out from RACF. thanks, Pete. _ Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch, Banc of America Securities Limited and Banc of America Futures Incorporated are regulated by the Financial Services Authority. _ ** 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: How Often Do You Reboot? -- Thanks!
Title: Message I just wanted to thank everyone who answered this query. -- Rebecca And for those in the US -- Have a Happy Fourth!! -Original Message-From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: 01 July 2003 15:28To: [EMAIL PROTECTED]Subject: How Often Do You Reboot? Hi, everyone. The subject sort of asks the basic question... Here are some more details. We run MQSeries on multiple Sun Solaris boxes. Most boxes are running Solaris 2.8. Some MQ servers are at V5.2 and some at V5.3 (and one lone box is still running V5.1). Some are rebooted fairly frequently and some have been up for months. In many cases, MQSeries server is the only software running on the box, although some development servers also run other stuff. What I'd like is some feel for how frequently others reboot their boxes. Some time back, we had an issue where the resolution from IBM was to reboot the box. So, I thought scheduling regular reboots on those boxes that don't currently have them would not be a bad idea , but wondered how often. My thanks, as always -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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.**Click here to visit the Argos home page http://www.argos.co.ukThe 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 intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised.If you have received this message in error, please advise the sender by using your reply facility in your e-mail software.All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed.** ** 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.
How Often Do You Reboot?
Hi, everyone. The subject sort of asks the basic question... Here are some more details. We run MQSeries on multiple Sun Solaris boxes. Most boxes are running Solaris 2.8. Some MQ servers are at V5.2 and some at V5.3 (and one lone box is still running V5.1). Some are rebooted fairly frequently and some have been up for months. In many cases, MQSeries server is the only software running on the box, although some development servers also run other stuff. What I'd like is some feel for how frequently others reboot their boxes. Some time back, we had an issue where the resolution from IBM was to reboot the box. So, I thought scheduling regular reboots on those boxes that don't currently have them would not be a bad idea , but wondered how often. My thanks, as always -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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: Z990
Dave, a better place to ask this question would be on the mainframe listserv. Try [EMAIL PROTECTED] for the IBM_Main list. -Original Message-From: Dave Adam [mailto:[EMAIL PROTECTED]Sent: Monday, June 30, 2003 1:51 PMTo: [EMAIL PROTECTED]Subject: Z990has anyone had any experience with the Z990 box and maintenance levels of software we are installing the Trex and are at ZOS 1.4, TS 1.3, MQ 2.1, and the CA family of productsDave AdamSupervalu Home OfficeProject Specialist(952) 828-4736[EMAIL PROTECTED]A good friend will come bail you out of jail..but, a true friendwill be sitting next to you saying, "...that was fun."-- ** 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: MQ 5.3 Upgrade
John, I can't fully answer this since we are still running V5.2, but the notes I have say SCSQTBLE. I'd suggest checking to be sure that the ISPF set up you have matches that in the Setup Guide. And make sure you're using a V5.3 version and don't have an older one stashed away in some other dataset in the ISPTLIB concatenation (not unusual to do since there are usually only one or two members in TLIBs and it seems silly to add such a small library). This probably isn't the level of detail you'd like, but it's a start. Hope it helps! -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: listname ANONYMOUS postings DIGests [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: MQ 5.3 Upgrade On December 20th of 2002 there was a thread that discussed people's experiences of upgrading from 2.1 to 5.3 on the mainframe. One response given was from Rebecca Bullock who mentioned some general upgrade things to look at. Thanks Rebecca for your advice. On her point 5 she states: "Based on what I've seen from other postings on this listserv -- You will need an additional ISPF library (in the ISPTLIB concatenation) to use the admin panels. The symptom of leaving this out is that the F4 prompt for object type on the main panel doesn't work right" What is the name of this "additional ISPF library"? We have encountered this particular problem and need your help. Thank You, John Haraburda TPS/ITS/Database Technologies Group MQSeries Office : 412-762-8548 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 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: MQ 5.3 Upgrade
John, sorry, but I can't help you there since we are still running V5.2. -Original Message- From: listname ANONYMOUS postings DIGests [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: MQ 5.3 Upgrade On December 20th of 2002 there was a thread that discussed people's experiences of upgrading from 2.1 to 5.3 on the mainframe. One response given was from Rebecca Bullock who mentioned some general upgrade things to look at. Thanks Rebecca for your advice. On her point 5 she states: "Based on what I've seen from other postings on this listserv -- You will need an additional ISPF library (in the ISPTLIB concatenation) to use the admin panels. The symptom of leaving this out is that the F4 prompt for object type on the main panel doesn't work right" What is the name of this "additional ISPF library"? We have encountered this particular problem and need your help. Thank You, John Haraburda TPS/ITS/Database Technologies Group MQSeries Office : 412-762-8548 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 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: monitoring
Lizette, I've toyed with trying this and I think it will work, but I've never actually done it... On one of a distributed platform qmgrs, you can use runmqsc to send the appropriate commands to the desired qmgr; your responses will come back to the machine you're on (but I don't remember exactly which queue they come back to). Then you just parse it out I'm mostly an OS/390 person with a smattering of Unix and don't know that much about NT. On Unix, you can use cron to check stuff periodically. Under NT, isn't there a Task Scheduler? Or AT? Could those be used to start the runmqsc at intervals? One thing I have done on OS/390 when we are having a stress test or are expecting particularly heavy volume is a "regurgitating" job that issues a QSTATS for the queues of interest, then goes to sleep and submits itself. Here's the job: //STEP1 EXEC PGM=CSQUTIL,REGION=8M,PARM='XXX' //STEPLIB DD DSN=MQSERIES.SCSQANLE,DISP=SHR // DD DSN=MQSERIES.SCSQAUTH,DISP=SHR //*YSPRINT DD SYSOUT=* //SYSPRINT DD DSN=TECH.RAB.XXX.STATS.DATA, // UNIT=3390,VOL=SER=OP42CF,SPACE=(CYL,(30,30)), // LRECL=80,BLKSIZE=0,RECFM=FB, // DISP=(MOD,KEEP) //CSQOUTX DD SYSOUT=* //SYSINDD * COMMAND DDNAME(CSQUCMD) /* //CSQUCMD DD * DISPLAY QL(XXX.REG*) CURDEPTH DISPLAY QL(XXXMQP*) CURDEPTH DISPLAY QL(INITQ.IDMS.PROD) CURDEPTH RESET QSTATS(XXX.REG*) RESET QSTATS(XXXMQP*) RESET QSTATS(INITQ.IDMS.PROD) /* //STEP2 EXEC PGM=WAITABIT,PARM='0005' //STEP3 EXEC JOB,N=CSQUTIL,LIB='RAB2567.CNTL.CNTL' Basically, the first step takes a snapshot of the queue statistics and the current depths. The second step is a homegrown utility that does nothing but wait (for 5 minutes here). And the third step submits the same job, in effect, making a loop. To stop it, just cancel the job. Then I run the output through a SAS program that slices and dices the output and makes reports and graphs. Not exactly real time monitoring, but OK for a day or so for something special. And it is free... Anyway, hope this gives you some ideas -- Rebecca -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 3:29 PM To: [EMAIL PROTECTED] Subject: monitoring Does anyone know of a way to gather statistics for MQSeries 5.2 running on NT and OS/390 that is free? --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: 2017 - Maxhands exceeded
Ah, I misunderstood. Sorry about that... -Original Message- From: Kearns, Emile E [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 8:54 AM To: [EMAIL PROTECTED] Subject: Re: 2017 - Maxhands exceeded Importance: High It finds a HCONN but returns a MQRC_HCONN_ERROR (2018, X'7E2') Connection handle not valid. Why??, I do not know. -Original Message----- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: 13 June 2003 02:34 To: [EMAIL PROTECTED] Subject: Re: 2017 - Maxhands exceeded Emile, could you be running out of handles because the MQCMIT can't find the hconn and it's starting a new one somehow? That would make the big question "why has he lost the hconn at the mqcmit?". I'd concentrate on trying to solve that and see if the max handles thing doesn't then just clear up. -Original Message- From: Kearns, Emile E [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:32 AM To: [EMAIL PROTECTED] Subject: 2017 - Maxhands exceeded Importance: High Hi all, One of the application people in my team gets the above error, I have allready set maxhands to 1024. His program logic looks like this: MQBEGIN MQCONN MQOPEN MQGET/PUT UPDATE DB MQCMIT (here, if he tries to use the current handle, MQ gives an error about the handle, can't remember what is is) MQBEGIN ( ideally , he does not want to begin again, should he, ie. , is this necessary?) MQGET/PUT UPDATE DB MQCMIT etc. Any ideas?? For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. II 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 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 For information about he Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. I 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 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: 2017 - Maxhands exceeded
Emile, could you be running out of handles because the MQCMIT can't find the hconn and it's starting a new one somehow? That would make the big question "why has he lost the hconn at the mqcmit?". I'd concentrate on trying to solve that and see if the max handles thing doesn't then just clear up. -Original Message- From: Kearns, Emile E [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:32 AM To: [EMAIL PROTECTED] Subject: 2017 - Maxhands exceeded Importance: High Hi all, One of the application people in my team gets the above error, I have allready set maxhands to 1024. His program logic looks like this: MQBEGIN MQCONN MQOPEN MQGET/PUT UPDATE DB MQCMIT (here, if he tries to use the current handle, MQ gives an error about the handle, can't remember what is is) MQBEGIN ( ideally , he does not want to begin again, should he, ie. , is this necessary?) MQGET/PUT UPDATE DB MQCMIT etc. Any ideas?? For information about the Standard Bank group visit our web site www.standardbank.co.za Disclaimer and confidentiality note Everything in this e-mail and any attachments relating to the official business of the Standard Bank Group Limited is proprietary to the group. It is confidential, legally privileged and protected by law. Standard Bank does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the group.The person addressed in the e-mail is the sole authorised recipient. Please notify the sender immediately if it has unintentionally reached you and do not read, disclose or use the content in any way. Standard Bank can not assure that the integrity of this communication has been maintained nor that it is free of errors, virus, interception or interference. II 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 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: "Export Queue Manager Definitions"
Hi, Michael. As Emile said, you basically use CSQUTIL. Here's JCL to do dump the object definitions to a flat file: == /*JOBPARM S= //* // SET MAKEDEF='MQSERIES..MAKEDEF.BACKUP' //* //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=&MAKEDEF,DISP=(MOD,DELETE),SPACE=(TRK,1),UNIT=3390 //* //UTIL EXEC PGM=CSQUTIL,REGION=8M,PARM='' //STEPLIB DD DSN=MQSERIES.SCSQANLE,DISP=SHR // DD DSN=MQSERIES.SCSQAUTH,DISP=SHR //SYSPRINT DD SYSOUT=* //CSQOUTX DD SYSOUT=* //OUTPUT1 DD DSN=&MAKEDEF., // UNIT=3390,VOL=SER=SYS019,SPACE=(TRK,(5,1)),DISP=(NEW,CATLG), // RECFM=FB,LRECL=80,BLKSIZE=0 //SYSINDD * COMMAND DDNAME(CSQUCMD) MAKEDEF(OUTPUT1) /* //CSQUCMD DD * DISPLAY STGCLASS(*) DISPLAY QUEUE(*) ALL DISPLAY NAMELIST(*) ALL DISPLAY PROCESS(*) ALL DISPLAY CHANNEL(*) ALL //* = If you're running on OS/390, you should probably be running this on a regular basis to backup your definitions (I do it once a week, scheduled through our scheduling package, CA7). Basically, you need to: 1) Run the above 2) Make any changes you might need for the new qmgr (channel names, CONNAMEs, etc) 3) Download it to the machine where the new qmgr lives 4) runmqsc < the.downloaded.file to load in the definitions Cheers, Rebecca -Original Message- From: Fleck, Michael [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 2:43 AM To: [EMAIL PROTECTED] Subject: "Export Queue Manager Definitions" Hi list members, I'm not very experienced dealing with MQSeries. We are running MQ-Series Server on OS/390. We want to migrate our server to Windows 2000. Is there a possibility to extract the MQ-Definitions (Queues, Channels etc.) from one server to import them on another server. Thanks in advance. Best regards, Michael Fleck Landschaftsverband Rheinland InfoKom Datenbanken, Ressourcen, OS/390 Tel: 0221/809/2826 email: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: OS/390 MQ Client Attach Feature compatibility.
Title: Message Pete, the CAF FMID will undoubtedly have a PRE for the base V5.3 FMID. You might be able to bypass the PRE for the base V5.3 FMID, but would it work? That's a question for Morag Hughson...And even if it DID work, I doubt you'd get support with any issues. -- Rebecca -Original Message-From: Peter Moir [mailto:[EMAIL PROTECTED]Sent: Wednesday, June 11, 2003 4:56 AMTo: [EMAIL PROTECTED]Subject: OS/390 MQ Client Attach Feature compatibility. We currently run MQ 5.2 on OS/390 2.10. We do not have the Client Attach Feature but have now ordered it. We need to get this in quickly before we upgrade MQ itself (later this year). I assume for MQ5.2 we need CAF v5.2. I've been on holiday and got back to be told that IBM have told us that CAF v5.2 is no longer shipped so are shipping us v5.3 instead. I assume that v5.3 CAF doesn't work with a v5.2 queue manager. Can anyone confirm that for me ? Can you run different releases of a queue manager and a CAF ?? 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. _ ** 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: MQ software evolution - fill in the gaps?
Wasn't TCAM (along with BTAM) a precursor to VTAM? (Although I may be wrong about that; it was a long time ago and is sort of lost in the mists of time. We were a BTAM shop, but as I remember, you had the choice of TCAM or BTAM.) -- Rebecca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 8:17 AM To: [EMAIL PROTECTED] Subject: Re: MQ software evolution - fill in the gaps? All, I thought ez-bridge came before MQSeries, unless it was Rel 1.0 of MQSeries which I'm certain was Release 2.0. By the by, TCAM (TeleCommuncationAccessMethod) wasn't messaging, it was the precursor to IMS and CICS, I think. I recall it was in use back in the early 1970's. "Heggie, Peter" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] NGRID.COM> cc: Sent by: MQSeriesSubject: Re: MQ software evolution - fill in the gaps? List <[EMAIL PROTECTED] n.AC.AT> 06/10/2003 12:06 PM Please respond to MQSeries List Not really, although I've had that thought. I'm trying to see where the two (or three) product lines overlap, see how that overlap has changed and try to estimate what will be left in a year or two. Peter Heggie (315) 428 - 3193 -Original Message- From: Fryett.Chris [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 11:20 AM To: [EMAIL PROTECTED] Subject: Re: MQ software evolution - fill in the gaps? Are you trying to show how ridiculous companies are getting with renaming their product line? -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 9:49 AM To: [EMAIL PROTECTED] Subject: MQ software evolution - fill in the gaps? Can someone help fill in the gaps or correct my note below? I'm trying to establish a timeline and show the names of the various MQ software names and dates. MQ: MQM (199? - 199?) -> MQSeries (199? - 2001) -> Websphere MQ (2001 - present) MQSI: MQSI (199? - 2000) -> WMQI (2000 - 2002) -> WMQIB (2002 - 2003) -> WBIMB (2003 - present) Workflow: ??? MQSI included NEON up until v2.2 Workflow now includes the Crossworlds technology? Which is named? WBIMB includes WBIEB, or you can get WBIEB separately..? Thanks! Peter Heggie National Grid, Syracuse, NY This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please contact the National Grid USA Enterprise Support Center on 508-389-3375 or 315-428-6360. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive * The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. 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 This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates. 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 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, co
Re: MQClient authorization error (2035)
Sony, I'm not familiar with NIS userids, but from the context, I'd guess they're like a single signon or a Windows domain signon? Is the userid you are using the same in both cases? MQ security on Unix is based on the user's group; does using NIS have any effect on the group assignment? One thing you could do is turn on Authority Events (I think the4 syntax is "ALTER QMGR AUTHOREV(ENABLED)", but that's from memory and should be checked. Then when you get the 2035, an event message should be written to the SYSTEM.ADMIN.QMGR.EVENT (wouldn't sear that's the right name, either). This should tell you in more detail where the problem lies. -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 11:50 AM To: [EMAIL PROTECTED] Subject: Re: MQClient authorization error (2035) Hi Rebecca, The scenario you have described is correct. My userid is a NIS userid id .. There's no seperate security set up for the queue manager Regards Sony -----Original Message- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: 02 June 2003 16:20 To: [EMAIL PROTECTED] Subject: Re: MQClient authorization error (2035) Sony, it's unclear from your question exactly what your issue is. Here's what I think you're asking: On Unix box A, you set up the MQSERVER variable (or a client channel table) which connects you to Unix box B. Then when you try to use amqsputc on A, you get a 2035 error. If, however, you log in on Unix box B and use amqsput, it runs fine. If this correct, then: Is the userid you are using on A defined on B and if it is, have you set up security to allow that userid to connect and to write to the queue? Just a thought, based on what I think you're asking -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 10:58 AM To: [EMAIL PROTECTED] Subject: MQClient authorization error (2035) Hi , I'm getting a 2035 error when I run amqsputc (MQClient) on a UNIX box. If I log in to the UNIX box where MQSeries is installed and run amqsput (MQServer), the program works fine. If it works fine on the server, shouldn't it also work fine on the client? Any idea why this happens? Do reply Regards Sony 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 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 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 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: MQClient authorization error (2035)
Sony, it's unclear from your question exactly what your issue is. Here's what I think you're asking: On Unix box A, you set up the MQSERVER variable (or a client channel table) which connects you to Unix box B. Then when you try to use amqsputc on A, you get a 2035 error. If, however, you log in on Unix box B and use amqsput, it runs fine. If this correct, then: Is the userid you are using on A defined on B and if it is, have you set up security to allow that userid to connect and to write to the queue? Just a thought, based on what I think you're asking -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Sony Varghese [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 10:58 AM To: [EMAIL PROTECTED] Subject: MQClient authorization error (2035) Hi , I'm getting a 2035 error when I run amqsputc (MQClient) on a UNIX box. If I log in to the UNIX box where MQSeries is installed and run amqsput (MQServer), the program works fine. If it works fine on the server, shouldn't it also work fine on the client? Any idea why this happens? Do reply Regards Sony 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 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: MQ 5.2 on Solaris - unable to load amqzfu
Ben, don't know if this is any help, but I have seen this message or something very similar. It turned out to be the result of a broken base installation. To check for this, try removing the maintenance package and running crtmqm; if it works, then perhaps you have the same problem we had (crtmqm worked fine at the base level but not when maintenance was put on). What turned out to be the problem was that the guy who installed MQSeries for me had installed only one component, then had looped back and installed a second component separately (in our case, it was the client that was added). This caused MQ to store in the install package parms info that only the client was installed, even though all of MQ server was installed. Then when the CSD was put on on top of the base, only the client pieces were installed since it thought that was all that was there. This made us end up with modules from a mix of levels and the result was the weird unable to load authorization module message when I tried to create a qmgr. You can actually check what components were installed by going to /var/sadm/pkg/mqm/pkginfo and looking at variable CLASSES. (Might be easier than removing the CSD.) Hope this helps -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE Princeton, NJ 08541 email: [EMAIL PROTECTED] / [EMAIL PROTECTED] -Original Message- From: Benjamin Zhou [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 4:37 PM To: [EMAIL PROTECTED] Subject: MQ 5.2 on Solaris - unable to load amqzfu Hi, we have two Solaris boxes, BOX_1 has mq, mqsi, workflow. everything is working fine. BOX_2 has Websphere, and MQSeries installed. when we try to create a qmgr after installation, we got the msg below. Has anyone experienced similar problems? appreciate sharing your knowledge. Ben Zhou State Street Corp. $ crtmqm TEST4 The system could not load the module '/opt/mqm/lib/amqzfu' for the installable service 'AuthorizationService' component 'MQSeries.UNIX.auth.service'. The system return code was 536895861. The Queue Manager is continuing without this component. MQSeries queue manager created. AMQ8146: MQSeries queue manager not available. ** 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: Expiry and triggering
Wesley, without going into the unholy mess you just started by mentioning "every" with the word "trigger", it will do away with messages that it would have read that are expired. For example, if you had the following messages on the queue: Msg1 -- expired Msg2 Msg3 -- expired And were triggered and you read one message (with no msgid or correlid, so it's a sequential read from the top), Msg 1 would be chucked and you'd get Msg2. But Msg 3, since you never read that far, would remain. -Original Message- From: Wesley Shaw [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 2:13 PM To: [EMAIL PROTECTED] Subject: Re: Expiry and triggering If a trigger is set to trigger on every, and there are messages that expire after they arrive on that queue, will the next triggered get do away with all expired messages ? "Potkay, Peter M (PLC, IT)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]cc: RTFORD.COM>Subject: Re: Expiry and triggering Sent by: MQSeries List <[EMAIL PROTECTED] AC.AT> 04/04/03 01:52 PM Please respond to MQSeries List An expired message would never arrive. Expiry is only decremented while the message is on a queue. If it expires on a transmit queue, then the MCA will not be able to ship it over. If it arrives on your triggered queue with an Expiry of at least 1/10 of a sec, then it does contribute to triggering conditions. In the case of depth, lets say your queue is triggered on depth of 5. If 4 messages sit on the queue and expire, the queue depth is still 4. When the 5th message arrives, your trigger will fire, but the app will only find 1 valid message. -Original Message- From: Wesley Shaw [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:45 PM To: [EMAIL PROTECTED] Subject: Expiry and triggering Does an expired message trigger a queue when it arrives ? 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 communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. 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 ** 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: PSID management
Larry, the place to start is one of the performance SupportPacs. Find the one for the version/release you are running and take it from there. As to why your monitor isn't indicating a problem... I don't believe that these particular problems cause event messages and perhaps your monitor only watches the event queues? Or maybe it doesn't consider it critical since you aren't at a lot of extents on your pagesets after all, being VSAM, these can go into many, many extents), but the volume's too full to take a needed new extent. Hard to say, although perhaps your monitor vendor could offer some insight. Regards, Rebecca -Original Message- From: Larry Murray [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 1:26 PM To: [EMAIL PROTECTED] Subject: PSID management Hello YET AGAIN!! Where can I get some info on Page management by MQ? In researching my 2192 issue we had, I found a few messages indicating buffer pool 1 is too small. I am going to created a few more PSID's and increase the size of the buffer pools. But as I said yesterday, I am confused as to why my MQ monitors never indicate an issue with PSID or buffers, but the messages show up every now and then. Thank you all for such great help. Larry Larry Murray Putnam Investments Tech Services 1-617-760-3270 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 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: 2192
Larry, could you have a program (I hope in testing) that went nuts and looped while writing messages? And then when it failed, it backed everything out? Since you have only 1% utilization, whatever it was must have either backed them out or you must have had something reading them in and consuming them. Or -- is the 1% an aggregate? Could you have one tiny pageset that is full and much larger ones that aren't (resulting in an average utilization of 1%)? Although I can't imagine them being that unevenly sized. Or is it possible that it was a transmission queue that was the problem, the channel finally started, and the messages are now clogging up some other qmgr? Just a couple of thoughts... If I had to guess, I'd guess the nutso test program. Good luck -- Rebecca -Original Message- From: Larry Murray [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:17 PM To: [EMAIL PROTECTED] Subject: 2192 Good afternoon All, What would cause a queue manager to suddenly beging spewing the following set of error msgs? CSQN203I .MQPA API COMPLETION CODE=2, REASON CODE=2192 CSQN212I .MQPA COMMAND SERVER ERROR PUTTING TO REPLY TO QUEUE I can read the manual and according to it, a Page set was full. BUT.never had anything like this before. Monitoring of the MQ system shows Page data sets 1 % used. Buffer pools always less than 15 % used. Then suddenly..bm. Any help on identifying possible causes of this will be met with a smile!!! Thank you Larry Murray Putnam Investments Tech Services 1-617-760-3270 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 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: Basic Question
Here's another thing to look at... I discovered by accident the other day that at least one program provided by IBM personnel to browse/display queue data does a conversion even if no format is specified. This is very handy when you are debugging something and the programmer "forgot" to set the data format to MQFMT-STRING, but it can make it difficult to tell that the problem with a cross-platform app is that the programmer didn't set it... Perhaps the MQ Explorer also just does a conversion despite the format? (I don't have a Windows qmgr, so I can't try this myself.) The channel can't do the conversion if there's no format specified. Just a thought... Rebecca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 9:02 AM To: [EMAIL PROTECTED] Subject: Basic Question We are using MQ to send messages back and forth from Win2k to VSE. We have CONVERT set to yes on the channel. When the VSE application sends messages to WIN2k I can browse the message using MQ Explorer and it looks fine (converted ok). When I plugged in my application (Seebeyond using it MQ Series adapter) the message came back unintelligible (probably because it didn't convert). My question is this: Is the message sitting on the queue in its converted form or does MQ Explorer do the conversion when the message is browsed? If the answer to 1 is that the message is unconverted on the queue, will setting the convert option on the mqget resolve this? Thank you in advance for any help Ken Plotnick Horizon Blue Cross Blue Shield NJ EDI Servvices Department ** This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use, or distribution of the information included in this message is prohibited -- please immediately and permanently 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 ** 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: Need to move stuff from one xmitq to another
Perhaps the author will be willing to share it. Since it's not mine, I don't feel I can just share it out. -- Rebecca -Original Message- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 1:04 PM To: [EMAIL PROTECTED] Subject: Re: Need to move stuff from one xmitq to another Any chance of sharing that program? Is it publicly available somewhere? -Original Message----- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 12:54 PM To: [EMAIL PROTECTED] Subject: Re: Need to move stuff from one xmitq to another Stefan, thanks. Actually, someone sent me a program that does what I want (Thanks, again, Jan!) The possibility that B and C would have to know about each other under normal circumstances was the reason I didn't go with the qmgr alias. Thanks, Rebecca -Original Message- From: Raabe, Stefan [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 2:38 AM To: [EMAIL PROTECTED] Subject: AW: Need to move stuff from one xmitq to another Rebecca, I do not know a supportpac that is doing exactly what you want. I think you have to write your own program (or channel exit) to change the queuemanagername. Anyway, the easiest way is a qmgr alias that is defined on QMGRC and makes QMGRC accept messages that are destined for QMGRB "define remoteq(QMGRB) RQMNAME(QMGRC)" If this is not possible because QMGRC has to know QMGRB as a seperate queuemanager, you should consider to - define the alias only in the case of a disaster or - to "fake" QMGRB, (e.g. use QMGRX as a destination for the messages and have a qmgr alias for QMGRX on QMGRB and QMGRC) I prefer the qmgr alias solution instead of programing. But - if programing is the only possible way to go - i would use a channel message exit. Regards, Stefan -Ursprüngliche Nachricht- Von: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. März 2003 17:17 An: [EMAIL PROTECTED] Betreff: Need to move stuff from one xmitq to another I am planning a backup/recovery scenario. The environment is OS/390 V5.2. . Basically, I have a bunch of messages on a transmission queue all ready to go to another qmgr (B). These messages specify RemoteQmgr B in their headers. I want to move them so they go to qmgr C. I know that I can move them to xmitq C so they will go to qmgr C (It's a bit awkward because of the get being disabled, but I can get around that). The problem/concern is that when the messages end up on C, they end up in the default XMIT queue because the transmission header has the RemoteQmgr set to B I've thought through several things using qmgr aliases and stuff like that, but rejected them for various reasons. (And before someone asks, I don't want to use clustering for this for several reasons I don't want to go into here.) It seems to me that the easiest way to do what I want is to write a simple program to read in the messages and modify the transmission header to point to RemoteQmgr C. Or, I suppose, I could strip the header and let MQ rebuild the header. But, I don't want to reinvent the wheel, which is why I'm putting this query out here Does anyone know of a SupportPac that will do this? (I went through the list, but didn't identify one that does what I want, but maybe I just missed it.) Or -- does someone have code they are willing to share? Remember -- It needs to run on OS/390. Thanks, all... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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 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 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
Re: Need to move stuff from one xmitq to another
Stefan, thanks. Actually, someone sent me a program that does what I want (Thanks, again, Jan!) The possibility that B and C would have to know about each other under normal circumstances was the reason I didn't go with the qmgr alias. Thanks, Rebecca -Original Message- From: Raabe, Stefan [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 2:38 AM To: [EMAIL PROTECTED] Subject: AW: Need to move stuff from one xmitq to another Rebecca, I do not know a supportpac that is doing exactly what you want. I think you have to write your own program (or channel exit) to change the queuemanagername. Anyway, the easiest way is a qmgr alias that is defined on QMGRC and makes QMGRC accept messages that are destined for QMGRB "define remoteq(QMGRB) RQMNAME(QMGRC)" If this is not possible because QMGRC has to know QMGRB as a seperate queuemanager, you should consider to - define the alias only in the case of a disaster or - to "fake" QMGRB, (e.g. use QMGRX as a destination for the messages and have a qmgr alias for QMGRX on QMGRB and QMGRC) I prefer the qmgr alias solution instead of programing. But - if programing is the only possible way to go - i would use a channel message exit. Regards, Stefan -Ursprüngliche Nachricht----- Von: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 27. März 2003 17:17 An: [EMAIL PROTECTED] Betreff: Need to move stuff from one xmitq to another I am planning a backup/recovery scenario. The environment is OS/390 V5.2. . Basically, I have a bunch of messages on a transmission queue all ready to go to another qmgr (B). These messages specify RemoteQmgr B in their headers. I want to move them so they go to qmgr C. I know that I can move them to xmitq C so they will go to qmgr C (It's a bit awkward because of the get being disabled, but I can get around that). The problem/concern is that when the messages end up on C, they end up in the default XMIT queue because the transmission header has the RemoteQmgr set to B I've thought through several things using qmgr aliases and stuff like that, but rejected them for various reasons. (And before someone asks, I don't want to use clustering for this for several reasons I don't want to go into here.) It seems to me that the easiest way to do what I want is to write a simple program to read in the messages and modify the transmission header to point to RemoteQmgr C. Or, I suppose, I could strip the header and let MQ rebuild the header. But, I don't want to reinvent the wheel, which is why I'm putting this query out here Does anyone know of a SupportPac that will do this? (I went through the list, but didn't identify one that does what I want, but maybe I just missed it.) Or -- does someone have code they are willing to share? Remember -- It needs to run on OS/390. Thanks, all... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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 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 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: Basic Question
Ken, when you put the message, did you specify MQFMT_STRING? If not, then the channel conversion can't happen. I'd have said "It's SeeBeyond" just a few days ago -- until I found out that under some circumstances, some of the browsing software provided by IBM people seems to convert it even if you don't have that turned on (Not having Windows MQ, I can't comment one way or the other on Explorer). So, I'd suggest you dump it with amqsbcg, just like Rick said, and see what it looks like in hex; that should answer the question as to whether the channel did the conversion or not. Cheers, Rebecca -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 9:02 AM To: [EMAIL PROTECTED] Subject: Basic Question We are using MQ to send messages back and forth from Win2k to VSE. We have CONVERT set to yes on the channel. When the VSE application sends messages to WIN2k I can browse the message using MQ Explorer and it looks fine (converted ok). When I plugged in my application (Seebeyond using it MQ Series adapter) the message came back unintelligible (probably because it didn't convert). My question is this: Is the message sitting on the queue in its converted form or does MQ Explorer do the conversion when the message is browsed? If the answer to 1 is that the message is unconverted on the queue, will setting the convert option on the mqget resolve this? Thank you in advance for any help Ken Plotnick Horizon Blue Cross Blue Shield NJ EDI Servvices Department ** This message and any attachments are solely for the intended recipient. If you are not the intended recipient, disclosure, copying, use, or distribution of the information included in this message is prohibited -- please immediately and permanently 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 ** 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
Need to move stuff from one xmitq to another
I am planning a backup/recovery scenario. The environment is OS/390 V5.2. . Basically, I have a bunch of messages on a transmission queue all ready to go to another qmgr (B). These messages specify RemoteQmgr B in their headers. I want to move them so they go to qmgr C. I know that I can move them to xmitq C so they will go to qmgr C (It's a bit awkward because of the get being disabled, but I can get around that). The problem/concern is that when the messages end up on C, they end up in the default XMIT queue because the transmission header has the RemoteQmgr set to B I've thought through several things using qmgr aliases and stuff like that, but rejected them for various reasons. (And before someone asks, I don't want to use clustering for this for several reasons I don't want to go into here.) It seems to me that the easiest way to do what I want is to write a simple program to read in the messages and modify the transmission header to point to RemoteQmgr C. Or, I suppose, I could strip the header and let MQ rebuild the header. But, I don't want to reinvent the wheel, which is why I'm putting this query out here Does anyone know of a SupportPac that will do this? (I went through the list, but didn't identify one that does what I want, but maybe I just missed it.) Or -- does someone have code they are willing to share? Remember -- It needs to run on OS/390. Thanks, all... Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 Phone: 609-734-5351 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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: Records updated from 2.1 to 5.3
Javier, I can't answer your question, but why not simply run a 3.12 comparing the two versions of the library? Cheers, Rebecca -Original Message- From: javier sotela [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 5:13 PM To: [EMAIL PROTECTED] Subject: Records updated from 2.1 to 5.3 Hi Everyone: Does anybody knows wich records that are located in prefix.ACSQCOBC change from mq series 2.1 to Mq series 5.3. We are looking for differences between cobol records from one version to another. Is there any documentation about changes with this migration ??? Thanks. Javier S. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive ** 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: Running different versions of MQ
Stewart, what exactly do you mean by "due to other MQ programs called while using ISPF"? I would expect that any application programs that may run under ISPF wouldn't care what level of MQSeries you're running and could run with either version. So, I'd expect only the Admin dialog to care about the MQ version (and that mostly because of fields that may not be recognized by an older version). What I'd do is set up a first menu where you ask the user to identify the queue manager he's interested in (he shouldn't need to know the version, only the queue manager) and then use that to allocate (using LIBDEFs and ALTLIBs) the appropriate libraries. There should be no need for a special logon proc. -- Rebecca -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2003 1:38 PM To: [EMAIL PROTECTED] Subject: Re: Running different versions of MQ You may have to modify your ISPF panels to let the user specify if the queue manager is V1.2 or V5.3 and then allocate the appropriate copy of SCSQAUTH. "Herd, Stewart" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] S-INC.COM> cc: Sent by: Subject: Running different versions of MQ MQSeries List <[EMAIL PROTECTED] en.AC.AT> 03/20/2003 11:48 AM Please respond to MQSeries List Am I correct in my assumption..? We have a client who has stated that they would like to be able to run MQ 1.2 and MQ 5.3 simultaneously on the same LPAR. I had read about this in the MQ 5.3 Systems Setup Guide, and I just reviewed it again. This requires that the Early Code of the latest version be added to the Link List first, and then execution of multiple versions should be possible. However, the 'SYS1.SCSQAUTH' library is currently in the Link List. It appears this will have to be removed from the Link List and added to every batch region that accesses MQ. I believe it is already in all of the CICS regions. If I understand it correctly, the two libraries that represent the Early Code are 'SYS1.SCSQLINK' and 'SYS1.SCSQSNLE'. 'SYS1.SCSQAUTH' is dynamically allocated within the clist that runs the ISPF MQ panel. However, due to other MQ programs called while using ISPF, I think 'SYS1.SCSQAUTH' will need to be added to the STEPLIBs of all the TSOPROCs also. Thanks in advance Stewart 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 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: Channel problem
Edward, all I did for the immediate problem was increase the maxdepth for the DLQ and restart the channel. Then had the programmer fix the original problem (app had a typo in the REplyToQ name). But likely you've done that kind of thing already; I'd look at the suggestions from others... -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 2:27 PM To: [EMAIL PROTECTED] Subject: Re: Channel problem Yes, the messages get to the DLQ. But my question is why is it building up in the transmit queue... As far as I know the DLQ did not get full.. What if any did you do to alleviate the situation? Edward. -Original Message----- From: Bullock, Rebecca (CSC) [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 11:18 AM To: [EMAIL PROTECTED] Subject: Re: Channel problem Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning "GET" ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the "GET" ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 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 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 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: Channel problem
Edward, are you sure that some of the messages didn't go to the DLQ on the other end of your channel? I've seen this happen when the DLQ over there gets full; the channel stops and the messages start to build up in the transmission queue until it, too, is full. At least, I think that's what I remember happening, but it's been quite a while, so my memory may be a bit off. -- Rebecca -Original Message- From: Edward Pius [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 1:29 PM To: [EMAIL PROTECTED] Subject: Channel problem Hello, I have a very interesting situation. One of the applications using MQ forgot to service the queue (meaning "GET" ing messages from the queue). Hence, the queue filled up. But instead of trying to put the excess messages in the DLQ on the receiving side, it started filling up the transmit queue. Also, one of the side effects is that other applications using the same transmit queue were temporarily out of commission. I have also seen the receiver channel on the "GET" ing side pause. Has anybody come across this problem? The version of MQ is 5.2 with CSD05 on Windows 2000 cluster. Most of the times in order to solve the crisis what we have done is to stop and start MQ (which drains the messages in the queue which filled up) and everything starts to work fine. What am I missing here In appreciation, Edward Pius. 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 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: Data conversion on mainframe
Darren, sounds like it's time for something drastic. How about adding some kind a dump/snap just before your call. Or my personal favorite -- simply zap the preceding instruction to x'00' and force an S0C1 (or whatever it's called in CICS). Not pretty, but generally pretty effective. Or you can try adding a WTO and wrote out the data... Rebecca -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2003 5:25 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Rick, I have a rather unsophisticated environment - CEDF is the limit of my online debugging facilities and this doesn't step into the MQXCNVC call. The handle is fine for calls that follow the MQXCNVC call... wonder if it is a problem passing the parameters... Cheers Darren >From: Rick Tsujimoto <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Data conversion on mainframe >Date: Fri, 14 Mar 2003 15:37:52 -0500 > >Darren, > >If you have an online debugger, e.g. Intertest, just step throught the code >and see where the handle gets whacked. > > > > > Darren Douch > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > COM> cc: > Sent by: Subject: Re: Data >conversion on mainframe > MQSeries List > <[EMAIL PROTECTED] > en.AC.AT> > > > 03/14/2003 02:51 > PM > Please respond > to MQSeries List > > > > > >Thanks Rebecca. I am already setting my Hcon to the supplied default (and >using that same handle on other MQ calls quite happily before and after the >MQXCNVC call). > >Might have to resort to trying the samples (assembler only unfortunately) >and then seeing if I can link to them from C... certainly a more painful >route. Maybe Morag will post a response and save the day :) > >Cheers >Darren. > >- Original Message - >From: "Bullock, Rebecca (CSC)" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, March 14, 2003 4:20 PM >Subject: Re: Data conversion on mainframe > > > > Darren, while you don't have to do the MQCONN, I believe that there's >still > > a connection handle (after all, it's a parm you need to specify on your > > MQOPEN). Check what you have this set to (I think it's MQHC_DEF_HCONN >for > > CICS when you don't so the MQCONN) and that you haven't overwritten it. >HTH > > -- Rebecca > > > > Rebecca Bullock > > Computer Sciences Corporation > > MFCoE/Newark CS Team > > > > Educational Testing Service Account > > Princeton, NJ 08541 > > > > email: [EMAIL PROTECTED] or [EMAIL PROTECTED] > > > > > > -Original Message- > > From: Darren Douch [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 14, 2003 8:20 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Data conversion on mainframe > > > > > > Ian and others... > > > > I can't argue about MQGET - it works as described in the manuals. But I > > have a scenario where I can't use it... long story short is that I have >a > > couple of chained data structures in front of the message data itself, >plus > > I don't know at the time of the GET whether I want to convert it >'properly' > > (using MQ's codepage support) or improperly (using some homegrown >conversion > > tables that are needed to keep a downstream application happy). > > > > I've made a bit of progress - managed to build the module now (whether > > correctly I don't know) - but get 2018 - invalid connection handle - >which > > is a bit odd because CICS apps don't really need / use a connection >handle. > > > > Any more offers? > > > > Cheers > > Darren. > > > > > > > > > > > > > > >From: Ian Metcalfe <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: Data conversion on mainframe > > >Date: Fri, 14 Mar 2003 21:59:53 +1100 > > > > > >Hey Darren, > > > > > >If I understand what you're asking correctly, I believe the recommended >way > > >is to simply use MQGMO_CONVERT on any MQGET calls on queues that may > > >contain > > >messages from other platforms.
Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first
Title: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Keith, by "bridge" are you referring to the channels? I don't know if this will help, but a long time ago, we had something that sounds vaguely similar (although it was a Solaris system where you have Windows). What we ended up doing is having the dist. side: 1) Send STOP CHANNEL commands to the mainframe telling it to stop the sender channel to the sun side 2) Issue STOP CHANNEL commands for the sender channels on the distributed side. Then at restart: 1) Send START CHANNEL commands to the mainframe telling it to restart its sender channels 2) Issue START CHANNEL for the local sender The only thing you have to watch for is if you WANT the channels to be down and you do a reboot, although that could be scripted around. Since we have no Windows qmgrs, I don't know if you can do something similar, but at least you now got a response :-) Good luck! HTH -- Rebecca Rebecca BullockComputer Sciences CorporationMFCoE/Newark CS TeamEducational Testing Service AccountPrinceton, NJ 08541email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Friday, March 14, 2003 12:12 PMTo: [EMAIL PROTECTED]Subject: Re: MQ connection(s) from distributed side to Mainframe show Pend ing after server is dropped without dropping Bridge first Greetings: I am trying this again. I didn't get any responses from my first attempt at sending this issue to the list. Thanks, Keith Hessong Senior Programmer/Analyst Golden Rule Insurance Company -Original Message-From: Keith A. Hessong [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 11, 2003 10:32 AMTo: [EMAIL PROTECTED]Subject: MQ connection(s) from distributed side to Mainframe show Pending after server is dropped without dropping Bridge first Greetings: My shop is currently experiencing a problem with MQ Series between our distributed side and our mainframe side when a server is dropped and restarted on the distributed side without dropping the bridge first. My shop ends up having at least one of our mainframe connections showing up on the distributed side as "PENDING". Our environment is as follows: Distributed Side: MQ Series Version 5.2 MSMQ MQ Series Bridge within Host Integration Server WINDOWS 2000 MSMQ Service Pack 3 Mainframe Side: OS/390 Version 2.5 MQ Series 2.1 which is up to date on maintenance and is using ADOPTMCA parameter = YES What are we currently doing now when a server is dropped and restarted on the distributed side? 1) Everything seems to be OK if we are able to shut the bridge down before dropping the server and restarting it on the distributed side. 2) If a server is dropped and restarted and no work kicks off from the distributed side to the mainframe side, the channel on the mainframe can be stopped and restarted and everything seems to be OK. 3) If a server is dropped and restarted and work kicks off from the distributed side to the mainframe side, the channel on the mainframe must be forced down, messages must be waited on for arrival on the mainframe side to acknowledge loss of communication between the distributed side and the mainframe side, and the channel can be restarted on the mainframe side. I have a couple of questions. Are we handling what we are experiencing here correctly? If not, what should we be doing that we aren't doing? Any other suggestions? Thanks, Keith Hessong ** 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: Data conversion on mainframe
Darren, while you don't have to do the MQCONN, I believe that there's still a connection handle (after all, it's a parm you need to specify on your MQOPEN). Check what you have this set to (I think it's MQHC_DEF_HCONN for CICS when you don't so the MQCONN) and that you haven't overwritten it. HTH -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Darren Douch [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 8:20 AM To: [EMAIL PROTECTED] Subject: Re: Data conversion on mainframe Ian and others... I can't argue about MQGET - it works as described in the manuals. But I have a scenario where I can't use it... long story short is that I have a couple of chained data structures in front of the message data itself, plus I don't know at the time of the GET whether I want to convert it 'properly' (using MQ's codepage support) or improperly (using some homegrown conversion tables that are needed to keep a downstream application happy). I've made a bit of progress - managed to build the module now (whether correctly I don't know) - but get 2018 - invalid connection handle - which is a bit odd because CICS apps don't really need / use a connection handle. Any more offers? Cheers Darren. >From: Ian Metcalfe <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Data conversion on mainframe >Date: Fri, 14 Mar 2003 21:59:53 +1100 > >Hey Darren, > >If I understand what you're asking correctly, I believe the recommended way >is to simply use MQGMO_CONVERT on any MQGET calls on queues that may >contain >messages from other platforms. If it's a text message type, like MQSTR for >example, it'll automatically be converted to the appropriate type for the >platform you're on. > >This works in all cases in my experience, and manually converting within >the >application seems to be a bit of a waste of effort to me. > >Ian > >-Original Message- >From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Darren >Douch >Sent: Friday, 14 March 2003 21:29 >To: [EMAIL PROTECTED] >Subject: Data conversion on mainframe > > >Folks > >has anyone out there used this call on the mainframe? I'm trying to use it >in a C / CICS program and not having much joy building (linking) the >application (MQXCNVC not resolving). > >Can anyone tell me what MQ uses under the covers for data conversion on the >mainframe ie the equivalent of iconv on AIX... if I can't use MQXCNVC is >there some other way I can do character conversion? > >Thanks >Darren. > > > > > >_ >Overloaded with spam? With MSN 8, you can filter it out >http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059 > >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 _ Stay in touch with absent friends - get MSN Messenger http://messenger.msn.co.uk 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 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: PCF Commands on OS/390
Matt, when a channel stops, an event message is written. You can set up a trigger to fire on a message going to the channel event queue, then do whatever you deem appropriate. -Original Message-From: Long, Matthew Jr. (Inland) [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 9:40 PMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 1. In other words, I can't run PCF commands on OS/390? Where did you get this? 2. Any ideas on how to monitor channels on OS/390, to see if they are down? If they are down I would like to automatically restart with a program or job. 3. By any chance is there some software I can buy that will monitor channels on OS/390? Thanks! -Original Message-From: Beardsley, Bridgette [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 5:52 PMTo: [EMAIL PROTECTED]Subject: Re: PCF Commands on OS/390 The following table lists each WebSphere MQ platform that supports PCFs. Platform WebSphere MQ for Short name Compaq OpenVMS Alpha Compaq OpenVMS Alpha Compaq NonStop Kernel Compaq NSK iSeries OS/400(R) OS/2 OS/2 UNIX(R)(R) systems see Note below UNIX systems Windows NT(R) Windows -Original Message-From: Long, Matthew Jr. (Inland) [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 18, 2003 4:38 PMTo: [EMAIL PROTECTED]Subject: PCF Commands on OS/390 I'm successful at making a connection from Win2K to a OS/390 Mainframe using MQCONNX, but I can't run any PCF commands. These PCF Commands work fine on UNIX, VMS, NT, and Win2K, but not the Mainframe. Any ideas why this is? Thanks! ---Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003 ---Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.455 / Virus Database: 255 - Release Date: 2/13/2003 ** 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: How to unsubscribe from the list
You may leave the list at any time by sending a "SIGNOFF MQSERIES" command to [EMAIL PROTECTED] -Original Message- From: subhendu mohanty [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 16, 2003 9:12 PM To: [EMAIL PROTECTED] Subject: How to unsubscribe from the list Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day ** 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: messages out of order
Notice that Bobbee said "in the middle of the night". And since I assume you didn't mean 5am (as if!), you're probably out of luck. Likely, all they'd find is a lonely MQ admin... -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 4:19 PM To: [EMAIL PROTECTED] Subject: Re: messages out of order Tell me about it. They are usually here until 5:00. Have the MQ guys with the dark suits and glasses drop over. -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 1:59 PM To: [EMAIL PROTECTED] Subject: Re: messages out of order Basic rules for MQ-ing. APPLICATIONS DO NOT PUT MESSAGES ON THE DLQ!! Or the MQ guys with the dark suits and glasses come around in the middle of the night and break your fingers!!! BAD Design bobbee >From: "Anderson, Lizette T. (RyTull)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: messages out of order >Date: Wed, 12 Feb 2003 10:41:16 -0600 > >We have told apps this for years. The previous administrator thought this >was a good idea and we have had no luck in convincing otherwise. > >-Original Message- >From: mqm mqm [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 12, 2003 7:27 AM >To: [EMAIL PROTECTED] >Subject: Re: messages out of order > > >Lysette, > >Why are the messages delivered to the DLQ only to be >extracted and delivered to the RT.PRD.ORDFBREC.INB >queue ? > >Seems like an odd use of the DLQ. > >mqm > > >--- "Anderson, Lizette T. (RyTull)" ><[EMAIL PROTECTED]> wrote: > > Thanks for the information. Our applications > > programmers are of course > > saying this is not true. They insists this is an MQ > > problem so I have been > > looking through the manuals to prove it is not. > > Does anyone have any idea > > where I can find this information? > > > > -Original Message- > > From: Miller, Dennis [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 11, 2003 3:51 PM > > To: [EMAIL PROTECTED] > > Subject: Re: messages out of order > > > > > > For MQ to always deliver messages in the same > > sequence they were sent, one > > of the restrictions is that you not have a DLQ. > > > > > > > -Original Message- > > > From: Anderson, Lizette T. (RyTull) > > [SMTP:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 12:18 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: messages out of order > > > > > > Its on the server. > > > > > > -Original Message- > > > From: Hill, Dave [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 2:11 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: messages out of order > > > > > > > > > Ok. Now the picture is getting more clear. We > > corrected our problem by > > > delaying the application on the receiving end as > > well as setting the > > channel > > > to stay open for a longer time. I am assuming that > > this DLQ is not on a > > > mainframe. > > > > > > -Original Message- > > > From: Anderson, Lizette T. (RyTull) > > > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 2:57 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: messages out of order > > > > > > > > > Our remote queue is the dead letter queue. > > > > > > -Original Message- > > > From: Hill, Dave [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 1:19 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: messages out of order > > > > > > > > > You could be getting data locks ( resource > > locking ) that is not allowing > > > certain records from being "extracted" in order. > > We had a problem like > > this > > > and it was a timing problem in a database. > > > One question: > > > What is the dead letter queues process? > > > > > > -Original Message- > > > From: Anderson, Lizette T. (RyTull) > > > [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 11, 2003 2:07 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: messages out of order > > > > > > > > > I need to add. The mainframe is running OS/390 > > communicating with a > > > Windows 2000 server both running MQSeries 5.2. > > > > > > > -Original Message- > > > > From: Anderson, Lizette T. (RyTull) > > > > Sent: Tuesday, February 11, 2003 1:04 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: messages out of order > > > > > > > > Is it possible for messages to be delivered out > > of order? Please read > > the > > > > following from our application programmer: > > > > > > > > We had a problem last night. A couple of our MQ > > message were processed > > > > out of order. The MQ messages are for Score > > Order Entry feedback from > > the > > > > mainframe. The queue name is > > RT.PRD.ORDFBREC.INB. The sequence of > > > > process the messages take to reach the queue > > are: > > > > -The mainframe writes rec
Re: Volume testing of CICS requests
Peter, gee, there used to be programs that would do that for you, but I haven't heard of them in a very long time; wonder if they even still make those? I don't have a magic answer, but how about... You didn't mention if this transaction requires a needs to use a terminal. I am assuming not since you're starting it up from a batch program. How about writing a simple CICS transaction that does a START for a whole bunch of transactions at once (well, OK, I guess they wouldn't be at once, but they'd be darn close). You could have it start up, say, 20 tasks and then just start it up 5 times to get your 100. You could even trigger it 5 times (that should be closer together than typing in the transid 5 times). Or maybe you could schedule them all for the same future time using the EXEC CICS START. Just a thought... Good luck with it -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] -Original Message- From: Peter Heggie [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 3:04 PM To: [EMAIL PROTECTED] Subject: Volume testing of CICS requests How do people simulate/perform volume testing of MQ roundtrips that start and end in CICS? Messages go to Windows and back. We want to simulate CICS transactions that send one message at a time, so each iteration would do an MQPUT1. Is there a way, without having 100 people sitting at 100 CICS terminals and hitting enter at the same time, of simulating a load on the system? I'm writing a batch program to loop through a file full of requests, but still that is only sending messages one at a time.. I can't run more than two or three batch jobs at a time.. 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 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: Wish list for Conference
Thanks, Dennis. Actually, I think I played around with this and finally gave
up. It wasn't as easy as I thought it would be. As I remember (and it's hazy
since it was a long while back), the problem was that there's no terminal
facility to tie the userid to. But thanks for suggesting it. (Or did you
have a working model?)
-Original Message-
From: Miller, Dennis [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 28, 2003 2:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Wish list for Conference
> Sure would be nice to be able to easily restart the CICS trigger monitor
> and end up with the address space userid, the same as you get when it's
> started from the PLT.
Doesn't seem like much of a stretch to write a small program to accomplish
that.
Something like:
EXEC CICS ASSIGN STARTCODE(MYSTART) END EXEC
IF MYSTART NOT EQUAL "SD"
MOVE 'CKQC STARTCKTI' TO mydata (or build CKQC commarea
from input source)
EXEC CICS START(EIBTRNID) FROM (mydata ) USERID(myuserid) END-EXEC
EXEC CICS RETURN END-EXEC
END IF
EXEC CICS RETRIEVE INTO(mydata) END EXEC
EXEC CICS LINK PROGRAM('CSQCSSQ ') INPUTMSG(mydata)
EXEC CICS RETURN END-EXEC
> -Original Message-
> From: Bullock, Rebecca (CSC) [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 28, 2003 9:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Wish list for Conference
>
> Well, of course, some of us won't get to go to the conference :-( so I
guess
> the choice is to put 'em here. Here's a list I came up with...
>
> 1) I'd like to strongly second an earlier wish to have Java clients
support
> channel tables. I need this and I need it badly.
>
> 2) Also a Java thing. First, understand I'm not a Java programmer, but the
> impression I've gotten from reading others' postings (and I may be wrong
> here) is that if you're using the Java client, you must specify the userid
> and that Java won't pick up the userid from the task issuing the MQ calls.
> OK, if it's possible within the constructs and constraints of the
language,
> please make a change so that the userid is picked up from the task's
userid
> automatically, similar to the situation with the regular C client on an NT
> box.
>
> 3) I think many of us have seen the problem of not being able to start a
> channel when there are duplicates in the channel SYNCQ. The fix is to get
a
> utility from IBM (CSQ4SYNC on OS/390 and I'd guess there's something
similar
> on the distributed qmgrs). It would be nice if that utility were
distributed
> as part of the product. And, after all, what harm is there? If it's not
the
> problem and there are no duplicates, nothing will be deleted.
>
> 4) Sure would be nice to be able to easily restart the CICS trigger
monitor
> and end up with the address space userid, the same as you get when it's
> started from the PLT.
>
> 5) It seems that people are often asking from help with shutdowns. How
about
> sample startup and shutdown scripts for the distributed environments? At
> least it would get people started.
>
> 6) Based on an (unpleasant) experience where a Solaris sysadmin installed
MQ
> on a server for me and then we couldn't get crtmqm to work after putting
on
> the latest CSD... How about removing the part of the install script that
> allows you to loop back and select another option to install? Or at least
a
> warning that if you do that, trouble will ensue. And, if possible, how
about
> listing out interpreted CLASSES when you do a pkginfo? (Can you do that?
I
> don't know.) I learned more than an OS/390 person should ever need to know
> about Solaris install scripts and packages as a result of this simple (and
> very human) error.
>
> 7) Now here's one that I don't really expect anyone from IBM to take
> seriously, but I'm putting here anyway: How about some doc on setting up
MQ
> mainframe security in a nonRACF environment? This is actually a concern
with
> a multitude of IBM products for those of us in ACF2 shops (and, I would
> guess, other security packages, too). There's always a lot of "well, let's
> try this and see what happens". It's messy and error-prone. Actually, this
> would be a good collaborative project for those of us in this situation.
>
> Anyway, that's my semi-short list. Have fun in Las Vegas!
>
> -- Rebecca
>
> Rebecca Bullock
> Computer Sciences Corporation
> MFCoE/Newark CS Team
>
> Educational Testing Service Account>
> Princeton, NJ 08541
>
> email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
>
>
>
>
> **
> This e-mail and any
Re: Wish list for Conference
Well, of course, some of us won't get to go to the conference :-( so I guess the choice is to put 'em here. Here's a list I came up with... 1) I'd like to strongly second an earlier wish to have Java clients support channel tables. I need this and I need it badly. 2) Also a Java thing. First, understand I'm not a Java programmer, but the impression I've gotten from reading others' postings (and I may be wrong here) is that if you're using the Java client, you must specify the userid and that Java won't pick up the userid from the task issuing the MQ calls. OK, if it's possible within the constructs and constraints of the language, please make a change so that the userid is picked up from the task's userid automatically, similar to the situation with the regular C client on an NT box. 3) I think many of us have seen the problem of not being able to start a channel when there are duplicates in the channel SYNCQ. The fix is to get a utility from IBM (CSQ4SYNC on OS/390 and I'd guess there's something similar on the distributed qmgrs). It would be nice if that utility were distributed as part of the product. And, after all, what harm is there? If it's not the problem and there are no duplicates, nothing will be deleted. 4) Sure would be nice to be able to easily restart the CICS trigger monitor and end up with the address space userid, the same as you get when it's started from the PLT. 5) It seems that people are often asking from help with shutdowns. How about sample startup and shutdown scripts for the distributed environments? At least it would get people started. 6) Based on an (unpleasant) experience where a Solaris sysadmin installed MQ on a server for me and then we couldn't get crtmqm to work after putting on the latest CSD... How about removing the part of the install script that allows you to loop back and select another option to install? Or at least a warning that if you do that, trouble will ensue. And, if possible, how about listing out interpreted CLASSES when you do a pkginfo? (Can you do that? I don't know.) I learned more than an OS/390 person should ever need to know about Solaris install scripts and packages as a result of this simple (and very human) error. 7) Now here's one that I don't really expect anyone from IBM to take seriously, but I'm putting here anyway: How about some doc on setting up MQ mainframe security in a nonRACF environment? This is actually a concern with a multitude of IBM products for those of us in ACF2 shops (and, I would guess, other security packages, too). There's always a lot of "well, let's try this and see what happens". It's messy and error-prone. Actually, this would be a good collaborative project for those of us in this situation. Anyway, that's my semi-short list. Have fun in Las Vegas! -- Rebecca Rebecca Bullock Computer Sciences Corporation MFCoE/Newark CS Team Educational Testing Service Account Princeton, NJ 08541 email: [EMAIL PROTECTED] or [EMAIL PROTECTED] ** 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
