Re: WMQIv2 shutdown problem
John, Are you on WMQSI 2.1 CSD04? Where did you get CSD04 from? Regards, Kulbir. John Abbott [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04-Dec-2002 00:22 Please respond to MQSeries List [EMAIL PROTECTED] To:MQSERIES cc: Subject:WMQIv2 shutdown problem Hi, We have just upgraded an our MQSi system to WMQSI and have noticed a small problem which has stumped us a little. We have a broker and it just won't shut down the 1st execution Group (ie the default execution group). It will shut down all the others but never that one.All we get is an error in the syslog saying: syslog snip WMQIv210[4270]: (TEST_BROKER)[772]BIP2804E: The broker has detected that Execution Group Services, process ID 41542, has not shutdown. : TEST_BROKER.agent: /build/S210_P/src/AdminAgent/ImbAdminStore.cpp: 606: ImbAdminStore::FindAndReportAllLongRunningProcesses: : Once we issue a kill command on this process the broker shuts down not a problem and the mqsistop command returns the normal message: BIP8061I: Successful comamnd completion. The software revisions are WMQSI 2.1 csd04 MQ 5.2 csd 05 DB2 UDB 7.2 AIX 4.3.3.0 RML 10 Hardware is IBM RS/6000 pSeries 6C1 Any help would be greatly apreciated. Regards John Abbott PS: your list was very helpful with another similar problem on MQSeries. Many thanks to all that provided solutions. ** * IMPORTANT INFORMATION * This document should be read only by those persons to whom it is addressed and its content is not intended for use by any other persons. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Any unauthorised form of reproduction of this message is strictly prohibited. St.George is not liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt. **
Re: V5.3/V5.3.1 etc
Hi there,
Our Windows 2000 memo.ptf say it has no CSD applied, I'm assuming we have an old media package. What is the best way of getting hold of the CSD that we need to apply? When is CSD2 expected?
Thanks,
Kulbir.
Michael F Murphy/AZ/US/MQSolutions [EMAIL PROTECTED]
Sent by: MQSeries List [EMAIL PROTECTED]
03-Dec-2002 22:08
Please respond to MQSeries List [EMAIL PROTECTED]
To:MQSERIES
cc:
Subject:Re: V5.3/V5.3.1 etc
Great explanation, this helps a great deal. I am still concerned about mqver. Here is the output I get on both my Windows 2000 and Linux machines. Note that my Windows 2000 memo.ptf says it has CSD 1 but Linux says no CSD applied:
Name:WebSphere MQ
Version: 530
CMVC level: p000-L021011
BuildType: IKAP - (Production)
How can I tell the CSD applied with this? To me it is gibberish.
Mike Murphy
MQ Solutions, LLC
Mark Taylor [EMAIL PROTECTED] wrote:
Date Recieved:
[IMAGE]
12/03/2002 08:54:42 AM
To:
[IMAGE]
[EMAIL PROTECTED]
cc:
[IMAGE]
Bcc
[IMAGE]
Subject:
[IMAGE]
V5.3/V5.3.1 etc
Let me make one thing very clear: there is NO SUCH THING as V5.3.1
For a brief time, the download images were labelled that way, but it was
quickly corrected to say V5.3.0.1. That extra zero makes all the
difference.
The first tranche of V5.3 platforms were shipped mid-year, and we often
refer to those as the GA1 release.
Testing then continued on the extra platforms (Linux, OS/400) and a number
of fixes were made in cross-platform code. So, when the second set was
released (GA2) it made sense to refresh the manufacturing images of the
original set of platforms at the same time, so they were all at exactly the
same level. New shipments of the original platforms will all, in effect,
have CSD01 pre-applied.
However you could also get the same set of code by applying CSD01 to a GA1
platform. You will see the CSD level included in inventory commands such as
lslpp on AIX, wherever that's possible.
Two minor complications: CSD01 isn't separately downloadable at the moment,
because of a hitch dealing with the fact that it contains crypto code. We
are trying to sort that out urgently. (I believe some people have been sent
it directly, but can't be sure of that.)
And if you want to install on Windows XP you must get the new level, as the
earlier install code (which of course cannot be updated by CSD) explicitly
refused to allow you to put it on XP.
But when CSD02 arrives, you will be able to install it on top of a GA1
package, a GA2 package or a GA1+CSD01 package.
Mark Taylor.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive
{-®孊뾊婶x2¢륪)bb²ٮnūb¢v«z⌦㔲㬴輧^v)톢ⳛ ®�ڕK ®nך½¨¥i¹^j
Re: Keep Alive vs Heartbeat - What's the diff?
Funny - I'm sure I remember reading this on one of IBM's Hints and Tips web pages (a long time ago). Still, I can't find it now so I'll just have to put it down to old age! But Paul's explanation was very clear so thanks for asking the question. Cheers, Paul Potkay, Peter M (PLC, IT) [EMAIL PROTECTED] on 02/12/2002 17:39:42 Please respond to MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Paul Meekin) Subject: Re: Keep Alive vs Heartbeat - What's the diff? Heartbeat is valid for recievers. The below is from the Intercommunication Handbook. Quote HeartBeat This attribute is valid for sender, cluster-sender, server, receiver, cluster-receiver, and requester channels. Other than on OS/390 and OS/400, it also applies to server-connection and client-connection channels. On these channels, heartbeats flow when a server MCA has issued an MQGET command with the WAIT option on behalf of a client application. End Quote Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -Original Message- From: Paul Meekin [mailto:[EMAIL PROTECTED]] Sent: Monday, December 02, 2002 11:34 AM To: [EMAIL PROTECTED] Subject: Re: Keep Alive vs Heartbeat - What's the diff? If I remember correctly, Heartbeat only works for Sender channels, keepalive only works for receivers. Fuzzy on the details though This e-mail is from Energis Communications Ltd, 185 Park Street, London, SE1 9DY, United Kingdom, No: 2630471. This e-mail is confidential to the addressee and may be privileged. The views expressed are personal and do not necessarily reflect those of Energis. If you are not the intended recipient please notify the sender immediately by calling our switchboard on +44 (0) 20 7206 and do not disclose to another person or use, copy or forward all or any of it in any form. 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
MQ JMS query
Hi I am using IBM MQSeries 5.1 and trying to put messages from IBM WAS4.0 using JMS. I am required to set 'application indendity data' on the MQ message and send it. I am unable to do using JMS api? Plz help me in this, Thanks in advance, Rgds Vinodh * * * The information contained in this message is legally privileged and confidential information intended only for the use of the addressed individual or entity indicated in this message (or responsible for delivery of the message to such person). It must not be read, copied, disclosed, distributed or used by any person other than the addressee. Unauthorised use, disclosure or copying is strictly prohibited and may be unlawful. Opinions, conclusions and other information on this message that do not relate to the official business of any of the constituent companies of the TATA CONSULTANCY SERVICES shall be understood as neither given nor endorsed by the Group. If you have received this message in error, you should destroy this message and kindly notify the sender by e-mail. 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
Re: Large record size
Make sure your logs and pagesets are large enough to hold everything if there is any kind of failure, and your log archiving can handle it fast enough The messages may block other messages along the same channel so you might consider a separate channel if traffic warrants it. Anderson, Lizette T. (RyTull) To: [EMAIL PROTECTED] Lizette.Anderson@RYERScc: ONTULL.COMSubject: Large record size Sent by: MQSeries List [EMAIL PROTECTED] T 12/03/2002 06:22 PM Please respond to MQSeries List I have a programmer currently designing an MQ application who would like to send 900,000 persistent messages through MQ. The bytes per record is 1012. It will run on OS/390 to a Window 2000 server both running 5.2 MQ. Are there any negative affects to sending this many records? It is by far the largest record size we have defined and I am concerned. --- 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 The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: WMQIv2 shutdown problem
we had this same problem yesterday. I cannot remember if the EXG was 'default' We naturally assumed it was because the developer had a debug session going and the EXG could not terminate the transaction. We too killed the process and everything was ok after that. bobbee From: John L. Gavin [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: WMQIv2 shutdown problem Date: Wed, 4 Dec 2002 08:40:58 - Actually we have CSD 3, but an lslpp shows 2.1.0.4 -Original Message- From: Kulbir S. Thind Sent: Wed 12/4/2002 08:18 To: [EMAIL PROTECTED] Cc: Subject: Re: WMQIv2 shutdown problem John, Are you on WMQSI 2.1 CSD04? Where did you get CSD04 from? Regards, Kulbir. John Abbott [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04-Dec-2002 00:22 Please respond to MQSeries List [EMAIL PROTECTED] To:MQSERIES cc: Subject:WMQIv2 shutdown problem Hi, We have just upgraded an our MQSi system to WMQSI and have noticed a small problem which has stumped us a little. We have a broker and it just won't shut down the 1st execution Group (ie the default execution group). It will shut down all the others but never that one. All we get is an error in the syslog saying: syslog snip WMQIv210[4270]: (TEST_BROKER)[772]BIP2804E: The broker has detected that Execution Group Services, process ID 41542, has not shutdown. : TEST_BROKER.agent: /build/S210_P/src/AdminAgent/ImbAdminStore.cpp: 606: ImbAdminStore::FindAndReportAllLongRunningProcesses: : Once we issue a kill command on this process the broker shuts down not a problem and the mqsistop command returns the normal message: BIP8061I: Successful comamnd completion. The software revisions are WMQSI 2.1 csd04 MQ 5.2 csd 05 DB2 UDB 7.2 AIX 4.3.3.0 RML 10 Hardware is IBM RS/6000 pSeries 6C1 Any help would be greatly apreciated. Regards John Abbott PS: your list was very helpful with another similar problem on MQSeries. Many thanks to all that provided solutions. ** * IMPORTANT INFORMATION* This document should be read only by those persons to whom it is addressed and its content is not intended for use by any other persons. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Any unauthorised form of reproduction of this message is strictly prohibited. St.George is not liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt. ** _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 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
ZAP for increasing number of TCBs for CICS adapter
I seem to recall there was a ZAP at mq 2.1 for increasing the number of TCBs used by the CICS adapter from the standard 8, but cant find reference to it anywhere. If anyone knows anything about it or can point me to something equivalent for mq 5.2 Id greatly appreciate it. Thanks, Scott
CICS Bridge Start
Hello MQ Listers, Well, I'm verturing into another new subsystem and wondered if anyone is using the MQ-CICS 3270 Bridge? If so, how are you starting it? If the CKBR transaction ties up a terminal until the monitor ends, sounds like a bad choice. I prefer not to have an operator have to issue a transaction to start it, and we don't have automated operator-type software. Just curious to know what others are doing. Thanks! Jill Grine 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: WMQIv2 shutdown problem
Hi, We regularly see this problem on our development Broker. It usually occurs after a deploy and results in the execution group using a large amount of CPU. On our Production Broker we sometimes see each flow disconnecting from it's queue (without any error/message from WMQI). In both cases the agent no longer has control over the ExecGroup and only a cancel and restart will help. We've got two open PMR's at IBM, but so far no solution or even a hint to what might be the cause... Regards, Michael -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: woensdag 4 december 2002 14:15 To: [EMAIL PROTECTED] Subject: Re: WMQIv2 shutdown problem we had this same problem yesterday. I cannot remember if the EXG was 'default' We naturally assumed it was because the developer had a debug session going and the EXG could not terminate the transaction. We too killed the process and everything was ok after that. bobbee From: John L. Gavin [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: WMQIv2 shutdown problem Date: Wed, 4 Dec 2002 08:40:58 - Actually we have CSD 3, but an lslpp shows 2.1.0.4 -Original Message- From: Kulbir S. Thind Sent: Wed 12/4/2002 08:18 To: [EMAIL PROTECTED] Cc: Subject: Re: WMQIv2 shutdown problem John, Are you on WMQSI 2.1 CSD04? Where did you get CSD04 from? Regards, Kulbir. John Abbott [EMAIL PROTECTED] Sent by: MQSeries List [EMAIL PROTECTED] 04-Dec-2002 00:22 Please respond to MQSeries List [EMAIL PROTECTED] To:MQSERIES cc: Subject:WMQIv2 shutdown problem Hi, We have just upgraded an our MQSi system to WMQSI and have noticed a small problem which has stumped us a little. We have a broker and it just won't shut down the 1st execution Group (ie the default execution group). It will shut down all the others but never that one. All we get is an error in the syslog saying: syslog snip WMQIv210[4270]: (TEST_BROKER)[772]BIP2804E: The broker has detected that Execution Group Services, process ID 41542, has not shutdown. : TEST_BROKER.agent: /build/S210_P/src/AdminAgent/ImbAdminStore.cpp: 606: ImbAdminStore::FindAndReportAllLongRunningProcesses: : Once we issue a kill command on this process the broker shuts down not a problem and the mqsistop command returns the normal message: BIP8061I: Successful comamnd completion. The software revisions are WMQSI 2.1 csd04 MQ 5.2 csd 05 DB2 UDB 7.2 AIX 4.3.3.0 RML 10 Hardware is IBM RS/6000 pSeries 6C1 Any help would be greatly apreciated. Regards John Abbott PS: your list was very helpful with another similar problem on MQSeries. Many thanks to all that provided solutions. ** 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 attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** 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: Large record size
Lissette, We had a similar challenge recently on OS/390. In addition to Bob's comments below and others, the most limiting factor I found by far is logging because of the persistence. You will not be able to go any faster than the logging speeds of your disk. There is a support pac, MP16, that can offer you some help in understanding these issues. I suggest you read it and focus on the performance aspects of logging (e.g. Upper bound on persistent message capacity - DASD log data rate). Good luck. Thanks Frank -Original Message- From: Robert Broderick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 8:11 AM To: [EMAIL PROTECTED] Subject: Re: Large record size Lissette, We had an application that sent about 8,000 2k-4k MT942 reports from the MF to an Windows frontend server farm where the data was parsed and applied to a data warehouse. When we were sending those messages persistent and one at a time the amount of time was substantial. Granted there may have been network considerations. BUTwe blocked those messages into 4mb blocks and the destination dissasembled them. When we switched to blocking the messages the time to deliver was reduced SUBSTANTIALLY!!! This option is not always available. But if it is you may want to consider using it. Try to run some performance test of the throughput. This could be done without a sweat by modifing one of the supplied example programs (amqsput) to do a loop and changing the message size. bobbee From: Stefan Sievert [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Large record size Date: Tue, 3 Dec 2002 16:20:07 -0800 Hi Lizette, what exactly is your concern? Is it amount of data or number of messages? Or both...? Generally speaking, 1k is not really a big message. If you add the message descriptor and transmission header (roughly 450 bytes), you are talking about approc. 1500 bytes per message. If you look at the performance support pacs you will see that this is the average message size at which MQ throughput peaks, so I wouldn't worry about the size (it doesn't matter anyway, they say). ;-) Assuming you have enough disk space everywhere the messages touch a disk (XMITQ on /390, target queue on Win2K) and your log files are sufficiently defined, you should be fine. The real challenge will be to convince your programmer not to try to send all 900.000 messages in ONE unit of work, but to do frequent commits ;-) There is a queue manager parameter that limits the number of uncommited messages (I think on 390 its called MAXSMSGS), that will limit how many messages the application can put within a syncpoint. It is a good practice to design applications so that they can make use of 'reasonable' batch sizes (preferably configurable) so this limit is not reached (it causes an MQCC_FAILED with MQRC_BACKED_OUT, I think). Remember, the MCA on the mainframe will not even see the messages (and start transmitting them) until the application calls MQCMIT. I am assuming that they are put using MQPM_SYNCPOINT; first of all because they are persistent, secondly because it's the default on /390. Bottom line: I would be more concerned about a tunable design, using a configurable application batch size, than about sheer volume. Other opinions/aspects/remarks out there? Hope it helps a bit, Stefan From: Anderson, Lizette T. (RyTull) [EMAIL PROTECTED] Reply-To: MQSeries List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Large record size Date: Tue, 3 Dec 2002 17:22:39 -0600 I have a programmer currently designing an MQ application who would like to send 900,000 persistent messages through MQ. The bytes per record is 1012. It will run on OS/390 to a Window 2000 server both running 5.2 MQ. Are there any negative affects to sending this many records? It is by far the largest record size we have defined and I am concerned. --- 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 _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users
Re: CICS Bridge Start
Jill, no, we don't use the 3270 Bridge, but that's not relevant to your general question on how to start something up in CICS. How about using a sequential terminal? That's how we start up some stuff (or at least, I know for a fact that we used to do it that way). The CICS guy says we still do, so I guess it's still around (CICS TS 1.3)). And that way, you're not tying up a real terminal. Of course, you could try something fancier like an MPF exit fired up by one of the CICS startup messages (no automation package required for MPF, but you have to write the exit). Or maybe a PLTSI. But the sequential terminal is an easy approach. Best regards, Rebecca Rebecca Bullock Computer Sciences Corporation Educational Testing Service Account Princeton, NJ 08541 e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -Original Message- From: Jill Grine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 10:01 AM To: [EMAIL PROTECTED] Subject: CICS Bridge Start Hello MQ Listers, Well, I'm verturing into another new subsystem and wondered if anyone is using the MQ-CICS 3270 Bridge? If so, how are you starting it? If the CKBR transaction ties up a terminal until the monitor ends, sounds like a bad choice. I prefer not to have an operator have to issue a transaction to start it, and we don't have automated operator-type software. Just curious to know what others are doing. Thanks! Jill Grine 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: Sizing a Server
When you say 95,000 messages, in what time period does that reference. Is that per 8 hour day, per 24 hour day, per hour, etc? Assuming you meant the load to be spread out over an 8 hour period even a fairly basic Unix/Linux/NT server could handle this load. -Original Message- From: Wesley Shaw [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 10:04 AM To: [EMAIL PROTECTED] Subject: Sizing a Server I need help sizing a server to handle the following: This project is in support of a Call Center used during major system outages. We need to size a server which is connected to a frame relay connected to a external call center on one side and MVS querying DB2 on the inhouse side. This server/QManager will essentially be a router of sorts between this outside queue manager and our inside MVS queue manager. It will need to be able to handle 95,000 request messages at 13 bytes (+header), 95,000 reply message with 65% of them being 171 bytes, 5% at 1 byte and 30% at 511 bytes. Additionally, another group of messages coming in at 171 bytes at the same rate of 95k per hour. Although with this group, we were also thinking of batching these up to where we could send larger messages at 60 per hour. We are thinking a smaller sized Unix server would work fine, or maybe an NT server. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: CICS Bridge Start
CKBR needn't tie up a terminal; you can start it any number of ways without a terminal resource attached. Trigger on first, works quite nicely since CKBR will then start/end dynamically in response to message traffic. -Original Message- From: Jill Grine [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 7:01 AM To: [EMAIL PROTECTED] Subject: CICS Bridge Start Hello MQ Listers, Well, I'm verturing into another new subsystem and wondered if anyone is using the MQ-CICS 3270 Bridge? If so, how are you starting it? If the CKBR transaction ties up a terminal until the monitor ends, sounds like a bad choice. I prefer not to have an operator have to issue a transaction to start it, and we don't have automated operator-type software. Just curious to know what others are doing. Thanks! Jill Grine Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: problem with MO12 support pack
I was using the Starttool product to display the module. Looking into this further, it appears that the file transfer product we are using has problems with PDSE libraries. I tried transmitting the PDSSEQ library to the system I was working on and issuing the receive there and no longer encountered this problem. Thanks for your help. - Bruce Giordano john gilmore [EMAIL PROTECTED]To: [EMAIL PROTECTED] cc: Sent by: MQSeries List Subject: Re: problem with MO12 support pack [EMAIL PROTECTED] Wednesday December 4, 2002 11:49 AM Please respond to MQSeries List This message is generated, by the Loader, when it detects a PDS directory entry for the entry/alias/whatever it is being asked to bring into storage that is not that of a load module. It is possible for a library/load-module PDS to contain a bad directory entry, but are you sure you are not asking the Loader to bring a source module, object module or the like into storage? You say that the module CCP1LRPL 'looks OK' when you list it. How are you doing this and what are you seeing? In particular, are you looking at the library that the loader is trying to use? John Gilmore SystemCraft LLC (See attached file: C.htm) This message is generated, by the Loader, when it detects a PDS directory entry for the entry/alias/whatever it is being asked to bring into storage that is not that of a load module. It is possible for a library/load-module PDS to contain abad directory entry, but are you sure you are not asking the Loader to bring a source module, object module or the like into storage? You say that the module CCP1LRPL 'looks OK' when you list it. How are you doing this and what are you seeing? In particular, are you looking at the library that the loader is trying to use?John GilmoreSystemCraft LLC
MQ under transaction server 1.3
We are running MQSeries for OS/390 5.2. Are there any known problems with running MQSeries under transaction server 1.3? --- 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
Re: MQ under transaction server 1.3
Lizette, we are running TS 1.3 and MQ V5.2. We've had no problems, but I'd check PSP buckets for anything critical that may need to go on. You know, SOP stuff :-) -- Rebecca -Original Message- From: Anderson, Lizette T. (RyTull) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 3:28 PM To: [EMAIL PROTECTED] Subject: MQ under transaction server 1.3 We are running MQSeries for OS/390 5.2. Are there any known problems with running MQSeries under transaction server 1.3? --- 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: V5.3/V5.3.1 etc
On this I have answers from IBM.
1) The CMVC level is a build date. It is year, month, day. So where you see L021011 is 2002-10-11. Thanks James Kingdon.
2) IBM support tells me they acknowledge this is not the way mqver should work. There isn't a PMR on it but they will fix it probably in CSD 2. No official word on that, just an unofficial response. They don't know when CSD 1 will be available for download. There are problems with that version of the CSD.
Anyhoo, I am going to start upgrading servers in development environments for my client and see what happens.
Michael F Murphy/AZ/US/MQSolutions [EMAIL PROTECTED] wrote:
Date Recieved:
12/03/2002 03:08:25 PM
To:
[EMAIL PROTECTED]
cc:
Bcc
Subject:
Re: V5.3/V5.3.1 etc
Great explanation, this helps a great deal. I am still concerned about mqver. Here is the output I get on both my Windows 2000 and Linux machines. Note that my Windows 2000 memo.ptf says it has CSD 1 but Linux says no CSD applied:
Name:WebSphere MQ Version: 530 CMVC level: p000-L021011 BuildType: IKAP - (Production)
How can I tell the CSD applied with this? To me it is gibberish.
Mike Murphy
MQ Solutions, LLC
Mark Taylor [EMAIL PROTECTED] wrote:
Date Recieved:
12/03/2002 08:54:42 AM
To:
[EMAIL PROTECTED]
cc:
Bcc
Subject:
V5.3/V5.3.1 etcLet me make one thing very clear: there is NO SUCH THING as V5.3.1
For a brief time, the download images were labelled that way, but it was
quickly corrected to say V5.3.0.1. That extra zero makes all the
difference.
The first tranche of V5.3 platforms were shipped mid-year, and we often
refer to those as the GA1 release.
Testing then continued on the extra platforms (Linux, OS/400) and a number
of fixes were made in cross-platform code. So, when the second set was
released ("GA2") it made sense to refresh the manufacturing images of the
original set of platforms at the same time, so they were all at exactly the
same level. New shipments of the original platforms will all, in effect,
have CSD01 pre-applied.
However you could also get the same set of code by applying CSD01 to a GA1
platform. You will see the CSD level included in inventory commands such as
lslpp on AIX, wherever that's possible.
Two minor complications: CSD01 isn't separately downloadable at the moment,
because of a hitch dealing with the fact that it contains crypto code. We
are trying to sort that out urgently. (I believe some people have been sent
it directly, but can't be sure of that.)
And if you want to install on Windows XP you must get the new level, as the
earlier install code (which of course cannot be updated by CSD) explicitly
refused to allow you to put it on XP.
But when CSD02 arrives, you will be able to install it on top of a GA1
package, a GA2 package or a GA1+CSD01 package.
Mark Taylor.
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
"{-®ç-ì~æjv x2¢êæj)b b²Û.nÇ+b¢v«zè¾'^v)í
ââ²Û ®ñêÚK ®Á®×½¨¥i¹^jØm¶ÿà %²írÈb½èm¶ÿ¾f¤§·óIêâzÆ«r¯
