Pat Ferzola/EastDataCenter/TotalSystem is out of the office.
I will be out of the office starting 09/24/2003 and will not return until 09/26/2003. I will respond to your message when I return. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you 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 5.3 install problem on w2k
Hello, I am having trouble installing MQ v5.3 on a Win2k server. After the initial installation screens, the 'Prepare WebSphere MQ Wizard' starts. I get the following error: "An unexpected error has occurred while validating the security credentials of user 'DOMAIN\UserID'" The DOMAIN and UserID are both valid and work installing MQ on other machines without problems. This machine is also running WAS 5.0 with the embedded MQ uninstalled. Any thoughts? Anybody see anything like this before? Thanks in advance, Jeff
Re: Tivoli & WMQ on Solaris.
I don't think Tivoli does enqueue/dequeue at the current version. We put a request for an enhancement but I don't know when it's coming out. -Original Message- From: Antony Boggis [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 3:44 PM To: [EMAIL PROTECTED] Subject: Tivoli & WMQ on Solaris. I don't have much choice here at a client site on the monitoring tools (ie, Tivoli) but I have been unable (at this point) to find some answers to basic questions from the searching I have done through the Tivoli docs... I know that Tivoli can watch most of the major attributes I want (q-depth, DLQ, opprocs, ipprocs, channel status, etc)... BUT: I can't find anywhere what the timer granularity is... If I'm pushing 500+ messages per second at MQ, refreshing my stats every minute is not gonna cut it. ALSO: Can I watch enqueue/dequeue rates, or other values that are only available (I think) via PCF (ie through the command server) messages? Thanks for any feedback, tonyB. -- WMQ 5.2 (CSD06) on Solaris 5.8. 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: DLQ reason code = 265
Darry/Scott, Thanks for the quick response the issue has been resolved. There was a permissions issue on the server so the process definition couldn't execute. Thanks Bill C. -Original Message- From: Gorse, Darry E [IT] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 1:30 PM To: [EMAIL PROTECTED] Subject: Re: DLQ reason code = 265 Bill, I just entered your subject line into a google search: DLQ reason code = 265 and found this. Cheers, Darry DESCRIPTION OF PROBLEM FIXED FOR APAR SA92087 : --- The MQSeries trigger monitor program (QMQM/RUNMQTRM) places trigger messages to the dead-letter queue with a feedback code of 265 (MQFB_APPL_CANNOT_BE_STARTED) if it cannot start the triggered application. This is the correct behaviour. . The problem is that RUNMQTRM will do the same if the triggered program terminates with anything other than a zero exit status. What should happen is that after the triggered program has been successfully started, RUNMQTRM should not put any messages onto the dead-letter queue, irrespective of the return code from the user application being success or failure. CORRECTION FOR APAR SA92087 : - The following fixes have been applied to the MQSeries trigger monitor program. 54284TRIGGER MONITOR DOES NOT PASS MQTMC2 IN SINGLE QUOTES IY14251 RUNMQTRM DLQ TRIGGER MSGS MQFB_APPL_CANNOT_BE_STARTED CIRCUMVENTION FOR APAR SA92087 : None. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 1:20 PM To: [EMAIL PROTECTED] Subject: DLQ reason code = 265 Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQIPT
I think you need to run the mqiptservice.exe to install the mqipt as a service. Check out Chapter 13 of the manual. Ron --- Usha Suryadevara <[EMAIL PROTECTED]> wrote: > Guys, > > Documentation says MQIPT runs as a service, > and i assumed its a windows > service. It actually runs as a service where a > command prompt sits on your > desktop all the time the service is running. > > Is there a way i can make this service run in the > background or run as a > windows service? > > Thanks > Usha > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.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
Tivoli & WMQ on Solaris.
I don't have much choice here at a client site on the monitoring tools (ie, Tivoli) but I have been unable (at this point) to find some answers to basic questions from the searching I have done through the Tivoli docs... I know that Tivoli can watch most of the major attributes I want (q-depth, DLQ, opprocs, ipprocs, channel status, etc)... BUT: I can't find anywhere what the timer granularity is... If I'm pushing 500+ messages per second at MQ, refreshing my stats every minute is not gonna cut it. ALSO: Can I watch enqueue/dequeue rates, or other values that are only available (I think) via PCF (ie through the command server) messages? Thanks for any feedback, tonyB. -- WMQ 5.2 (CSD06) on Solaris 5.8. 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: New code pages
No, UQ75267 fixed the issue, then was sup'd by UQ76767. This was due to a page chain corruption with indexed queues. It always hit us on SYSTEM.CHANNEL.SYNCQ, which is in PSID00. In actuality, messages for the SYSTEM.ADMIN.CHANNEL.EVENT queue were being written to the SYNCQ. Whenever we shutdown the queue manager after the 5C6 abends (which sometimes were recursive, and other times, we would just get one abend), the queue manager could not restart. We ended up doing a cold start. The corruption can hit on any indexed queue. I can not explain why we ran fine for three months before we saw any problems. It seems that there is a small window of time when this could happen. The error hit us on 3 queue managers, and not on the other 40 that we currently run. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Ofeldt, Robert" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/24/2003 03:48 PM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: Re: MQ 5.2: New code pages Glen can you tell me if the problem below was due to PTF UQ75267 ? Also can you explain why you had to rebuild the Qmgr after the PTF was applied? Also do you know why you ran fine for 3 months before having the problem ? Thanks Bob Ofeldt -Original Message- From: Yeske, Judy [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2: New code pages Thanks Glen, I'll pass this along to our Software Install folks ! Judy -Original Message- From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 11:56 AM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2: New code pages We don't have the code pages documented, but I wanted to make you aware of an issue we have had with 5.3. Ensure that you have UQ76767 applied. This PTF supercedes UQ75267, which fixes a page chain corruption problem. We ran fine for approx 3 months, then CHINs started abending with a 5C6, and unable to get messages from the SYSTEM.CHANNEL.SYNCQ, rc=2195. We ended up rebuilding the queue managers to get around this problem, after the maint was applied. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Yeske, Judy" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/24/2003 09:38 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: MQ 5.2: New code pages Hello, I'm currently migrating my mainframe MQ subsystems from Version 2.1 to Version 5.3 (skipping 5.2). In reviewing the Version 5.2 System Setup Guide, it mentions new code pages being added, including one for Unicode. Does anyone have these documented ? Thanks in advance, Judy Yeske The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you 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. The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by
Re: WMQ 5.3 runmqtrm failure
Are you sure the job is failing? Did you check if the DB updates took place or not? Are you getting DLQ messages for the failing job? The reason I ask is because I had a similar problem, where I was getting DLQ messages for jobs that were triggered that supposedly failed. But, the jobs actually ran. I had to export the same var you mentioned below and it fixed my problem. I did the export in the shell script I used to start my queue manager, which includes my trigger monitor as well. Terrence J Serena To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: Re: WMQ 5.3 runmqtrm failure Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/24/2003 11:30 AM Please respond to MQSeries List Jim/Lail, Our programs are written in C. They only fix suggested by IBM was Apar IY31891. The workaround was to set environment variable: export AMQ_SIGCHLD_SIGACTION=YES. Which did not correct the problem. I have applied CSD #4. Jim Wendorf <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MUTUAL.COM> cc: Sent by: MQSeriesSubject: Re: WMQ 5.3 runmqtrm failure List <[EMAIL PROTECTED] n.AC.AT> 09/24/2003 10:07 AM Please respond to MQSeries List Are the programs written in Java?If they are, there are some Apars that relate to problems with runmqtrm and V5.3. Jim Terrence J SerenaTo: [EMAIL PROTECTED] <[EMAIL PROTECTED]>cc: Sent by: MQSeries List Subject: WMQ 5.3 runmqtrm failure <[EMAIL PROTECTED]> 09/24/2003 08:34 AM Please respond to MQSeries List I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry 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 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: New code pages
Title: Message Glen can you tell me if the problem below was due to PTF UQ75267 ? Also can you explain why you had to rebuild the Qmgr after the PTF was applied? Also do you know why you ran fine for 3 months before having the problem ? Thanks Bob Ofeldt -Original Message- From: Yeske, Judy [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 12:42 PM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2: New code pages Thanks Glen, I'll pass this along to our Software Install folks ! Judy -Original Message- From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 11:56 AM To: [EMAIL PROTECTED] Subject: Re: MQ 5.2: New code pages We don't have the code pages documented, but I wanted to make you aware of an issue we have had with 5.3. Ensure that you have UQ76767 applied. This PTF supercedes UQ75267, which fixes a page chain corruption problem. We ran fine for approx 3 months, then CHINs started abending with a 5C6, and unable to get messages from the SYSTEM.CHANNEL.SYNCQ, rc=2195. We ended up rebuilding the queue managers to get around this problem, after the maint was applied. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Yeske, Judy" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/24/2003 09:38 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: MQ 5.2: New code pages Hello, I'm currently migrating my mainframe MQ subsystems from Version 2.1 to Version 5.3 (skipping 5.2). In reviewing the Version 5.2 System Setup Guide, it mentions new code pages being added, including one for Unicode. Does anyone have these documented ? Thanks in advance, Judy Yeske The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you 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.
Re: DLQ reason code = 265
I'm running MQSeries 5.3, CSD03 on Windows 2k. -Original Message- From: Rick Tsujimoto [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 2:02 PM To: [EMAIL PROTECTED] Subject: Re: DLQ reason code = 265 Scott, What Version and CSD level are you running at, and what platform are you running on? Scott Gray <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: DLQ reason code = 265 MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/24/2003 02:31 PM Please respond to MQSeries List cmqc.h: #define MQFB_APPL_CANNOT_BE_STARTED 265L -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Conklin, William Sent: Wednesday, September 24, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: DLQ reason code = 265 Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. 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 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: DLQ reason code = 265
Scott, What Version and CSD level are you running at, and what platform are you running on? Scott Gray <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: Sent by: Subject: Re: DLQ reason code = 265 MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/24/2003 02:31 PM Please respond to MQSeries List cmqc.h: #define MQFB_APPL_CANNOT_BE_STARTED 265L -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Conklin, William Sent: Wednesday, September 24, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: DLQ reason code = 265 Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: DLQ reason code = 265
Bill,
Here is another item on this subject.
-Original Message-
From: Conklin, William [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2003 1:20 PM
To: [EMAIL PROTECTED]
Subject: DLQ reason code = 265
Hi There,
I've seen threads discussing the reason code of 265 in the dead letter
header but I can't seem to find them now. I can't find this reason code in
any of the documentation either. Suggestions? The put application name in
the DLH is runmqtrm and the destination queue is the initiation queue
defined for the local queue.
Thanks
Bill C.
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
Item RTA000167929
Source..: PDDBR PDDBR
Last updated: 20010129
Abstract: RUNMQDLQ INITIATED BY TRIGGER CAUSES DLQ ENTRIES FB265 265
USERS: ALL USERS with MQSeries Windows
PROBLEM SUMMARY:
Having trouble getting runmqdlq to be triggered when a
message appears in the Dead Letter Queue. When a message enters the
DLQ, a loop occurs because each iteration of runmqdlq causes a
FeedBack code of MQFB_APPL_CANNOT_BE_STARTED. But in fact the
application is started and messages are moved from DLQ to
DLQ.REALLY.DEAD.QUEUE as expected. Problem is with WAIT(NO) the
runmqdlq is executed once for each message and every execution of
runmqdlq causes another dead letter - thus a loop. It does not make
sense to me this would cause the MQFB_APPL_CANNOT_BE_STARTED
condition. If I say WAIT(YES) then another program I run that does an
MQINQ to check queue depth of the DLQ hangs until runmqdlq ends -
which never happens with WAIT(YES) specified - even if I open the
queue shared and DLQ options allow sharing of the queue.
SOLUTION:
We have seen a number of calls on this. What can happen is the
triggered application will start and run fine. Then when it returns a
non zero return code it will cause a trigger message to get written
to the DLQ with the return code you mentioned. What has been
suggested is to code the application so it will give a zero return
code for things like 2033 no messages to get.
There are three choices here:
1) Preface runmqdlq with the word 'START' in the process definition.
This will cause it to run in the background and ensure the
trigger message is not DLQ'd.
2) Modify the process definition to call a batch file which in turn
starts runmqdlq. So long as the batch file exits with a zero
return value, the trigger message won't be DLQ'd.
3) Use the source supplied under the 'samp' directory to modify and
rebuild runmqdlq. This is not particularly easy, but it is
possible.
I believe option 1 is easiest and best. It is important to not when
a triggered application runs in the background, the triggered monitor
immediately checks for new trigger messages, rather than waiting for
the triggered application to end.
Cust tried option #1 you offered. Setup the process as follows:
DEFINE PROCESS ('DLQHandler2') REPLACE +
DESCR('Dead Letter Queue Handler') +
APPLTYPE(WINDOWSNT) +
APPLICID('start C:\Program Files\MQSeries\bin\runmqdlq.exe
DLQ 7EPPF runmqdlq is not reading it's parameters properly.
Cust did find a solution. The problem was cust was triggering a
program (sort of an agent) via another queue that would try to browse
(1st method) or MQINQ (2nd method) the DLQ to see if any message was
on the queue. This was simply to trigger a central alert that there
were entries in the DLQ. The DLQ monitor was being triggered by the
DLQ trigger to process it too so we had two processes attempting to
access the DLQ. (it was all setup to supposedly share the queue but
the process that attempted the browse or MQINQ would hang). Never
could get that to work.
So I quit triggering runmqdlq with a trigger on the DLQ and instead
modified my C program to MQINQ the DLQ and if it was not empty to
START the runmqdlq from the C program. This works just fine. As far
as I am concerned the problem is resolved.
Re: DLQ reason code = 265
cmqc.h: #define MQFB_APPL_CANNOT_BE_STARTED 265L -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Conklin, William Sent: Wednesday, September 24, 2003 2:20 PM To: [EMAIL PROTECTED] Subject: DLQ reason code = 265 Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. 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: DLQ reason code = 265
Bill, I just entered your subject line into a google search: DLQ reason code = 265 and found this. Cheers, Darry DESCRIPTION OF PROBLEM FIXED FOR APAR SA92087 : --- The MQSeries trigger monitor program (QMQM/RUNMQTRM) places trigger messages to the dead-letter queue with a feedback code of 265 (MQFB_APPL_CANNOT_BE_STARTED) if it cannot start the triggered application. This is the correct behaviour. . The problem is that RUNMQTRM will do the same if the triggered program terminates with anything other than a zero exit status. What should happen is that after the triggered program has been successfully started, RUNMQTRM should not put any messages onto the dead-letter queue, irrespective of the return code from the user application being success or failure. CORRECTION FOR APAR SA92087 : - The following fixes have been applied to the MQSeries trigger monitor program. 54284TRIGGER MONITOR DOES NOT PASS MQTMC2 IN SINGLE QUOTES IY14251 RUNMQTRM DLQ TRIGGER MSGS MQFB_APPL_CANNOT_BE_STARTED CIRCUMVENTION FOR APAR SA92087 : None. -Original Message- From: Conklin, William [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 1:20 PM To: [EMAIL PROTECTED] Subject: DLQ reason code = 265 Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. 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
DLQ reason code = 265
Hi There, I've seen threads discussing the reason code of 265 in the dead letter header but I can't seem to find them now. I can't find this reason code in any of the documentation either. Suggestions? The put application name in the DLH is runmqtrm and the destination queue is the initiation queue defined for the local queue. Thanks Bill C. 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: WMQI v2.1 CSD 5 - Transactional Rollback
Chris: Thank you for your insightful help. We still had a few problems, but this is the resolution to our problem: 1. The MQInput node only had the out terminal wired. 2. The Compute node which called the 1-n SQL stored procedures reviewed the return codes and if it was an error it threw a user exception which forced the failure terminal on the compute node to become active. 3. We then constructed our error message, wrote it to an output error queue, and threw an exception to cause a transactional rollback 4. The error queue would be handled by another flow which would update an error table with the proper content 5. The MQInput node's queue backout count was set to 1 so the message would be thrown After extensive testing transactional rollback occurred. So, in summary would someone please put the ability to call COMMIT/ROLLBACK in a message flow so I don't have to jump through hoops again, arg! Thank you for your help. Regards, Chris & Satish |-+> | | "Christopher | | | Frank" | | | <[EMAIL PROTECTED]| | | COM> | | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 09/23/2003 03:09 | | | PM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: WMQI v2.1 CSD 5 - Transactional Rollback | | | >--| Chris, >>>No, I mean that a transactional rollback will occur first, >>>i.e. any inserts will be removed from a database, and then >>>the failure terminal will kick in. In WMQI the scope of a transaction is the message flow. That would include actions taken on any failure paths. Can I ask what action(s) are you taking on the failure path that cannot be performed before the rollback occurs? It is possible to have the failure path actions outside of the transaction, but they will still be executed before the transactional rollback occurs. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: MQ 5.2: New code pages
Title: Message Thanks Glen, I'll pass this along to our Software Install folks ! Judy -Original Message-From: Glen Shubert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 11:56 AMTo: [EMAIL PROTECTED]Subject: Re: MQ 5.2: New code pagesWe don't have the code pages documented, but I wanted to make you aware of an issue we have had with 5.3. Ensure that you have UQ76767 applied. This PTF supercedes UQ75267, which fixes a page chain corruption problem. We ran fine for approx 3 months, then CHINs started abending with a 5C6, and unable to get messages from the SYSTEM.CHANNEL.SYNCQ, rc=2195. We ended up rebuilding the queue managers to get around this problem, after the maint was applied.Glen Shubert[EMAIL PROTECTED]Associate DirectorTSYS - MQSeries Technical Support "Yeske, Judy" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/24/2003 09:38 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: MQ 5.2: New code pagesHello, I'm currently migrating my mainframe MQ subsystems from Version 2.1 to Version 5.3 (skipping 5.2). In reviewing the Version 5.2 System Setup Guide, it mentions new code pages being added, including one for Unicode. Does anyone have these documented ? Thanks in advance, Judy Yeske The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: MQ 5.2: New code pages
We don't have the code pages documented, but I wanted to make you aware of an issue we have had with 5.3. Ensure that you have UQ76767 applied. This PTF supercedes UQ75267, which fixes a page chain corruption problem. We ran fine for approx 3 months, then CHINs started abending with a 5C6, and unable to get messages from the SYSTEM.CHANNEL.SYNCQ, rc=2195. We ended up rebuilding the queue managers to get around this problem, after the maint was applied. Glen Shubert [EMAIL PROTECTED] Associate Director TSYS - MQSeries Technical Support "Yeske, Judy" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 09/24/2003 09:38 AM Please respond to MQSeries List To: [EMAIL PROTECTED] cc: Subject: MQ 5.2: New code pages Hello, I'm currently migrating my mainframe MQ subsystems from Version 2.1 to Version 5.3 (skipping 5.2). In reviewing the Version 5.2 System Setup Guide, it mentions new code pages being added, including one for Unicode. Does anyone have these documented ? Thanks in advance, Judy Yeske The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
Re: WMQ 5.3 runmqtrm failure
Jim/Lail, Our programs are written in C. They only fix suggested by IBM was Apar IY31891. The workaround was to set environment variable: export AMQ_SIGCHLD_SIGACTION=YES. Which did not correct the problem. I have applied CSD #4. Jim Wendorf <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MUTUAL.COM> cc: Sent by: MQSeriesSubject: Re: WMQ 5.3 runmqtrm failure List <[EMAIL PROTECTED] n.AC.AT> 09/24/2003 10:07 AM Please respond to MQSeries List Are the programs written in Java?If they are, there are some Apars that relate to problems with runmqtrm and V5.3. Jim Terrence J SerenaTo: [EMAIL PROTECTED] <[EMAIL PROTECTED]>cc: Sent by: MQSeries List Subject: WMQ 5.3 runmqtrm failure <[EMAIL PROTECTED]> 09/24/2003 08:34 AM Please respond to MQSeries List I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: WMQ 5.3 runmqtrm failure
Rick, Yes, they requested many traces. They don't appear to be showing any MQ failures. Rick Tsujimoto <[EMAIL PROTECTED]To: [EMAIL PROTECTED] .CANON.COM>cc: Sent by: MQSeries List Subject: Re: WMQ 5.3 runmqtrm failure <[EMAIL PROTECTED]> 09/24/2003 10:03 AM Please respond to MQSeries List Terry, I wouldn't accept that as an answer. Did they at least ask for a trace? Terrence J Serena To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: WMQ 5.3 runmqtrm failure Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/24/2003 09:34 AM Please respond to MQSeries List I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Risks of implementing Single Write Integrity
You will not gain much performance improvements to justify the risk! |-+> | | "Gurney, Matthew"| | | <[EMAIL PROTECTED]| | | SFB.COM> | | | Sent by: | | | "MQSeries List" | | | <[EMAIL PROTECTED]| | | n.AC.AT> | | || | || | | 09/24/2003 09:20 | | | AM | | | Please respond to| | | "MQSeries List" | | || |-+> >--| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Risks of implementing Single Write Integrity | | | >--| RE: Risks of implementing Single Write Integrity > Solaris 5.8 > MQ 5.2 CSD7 > > We are having some performance issues on our Queue managers lately and I was considering moving from Triple to Single Write Integrity. All disks are on an EMC SAN so I assume this is exactly the sort of situation that the Single Write Integrity option was designed for. > > Does anybody have any experience of this? I am interested in hearing about the possible performance improvements and the risks of moving from Triple to Single Write Integrity. > > Thanks in advance, > Matt. > > > == This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == 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
MQIPT
Guys, Documentation says MQIPT runs as a service, and i assumed its a windows service. It actually runs as a service where a command prompt sits on your desktop all the time the service is running. Is there a way i can make this service run in the background or run as a windows service? Thanks Usha Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Risks of implementing Single Write Integrity
risky -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Gurney, Matthew Sent: 24 September 2003 15:20 To: [EMAIL PROTECTED] Subject: Risks of implementing Single Write Integrity RE: Risks of implementing Single Write Integrity > Solaris 5.8 > MQ 5.2 CSD7 > > We are having some performance issues on our Queue managers lately and I was considering moving from Triple to Single Write Integrity. All disks are on an EMC SAN so I assume this is exactly the sort of situation that the Single Write Integrity option was designed for. > > Does anybody have any experience of this? I am interested in hearing about the possible performance improvements and the risks of moving from Triple to Single Write Integrity. > > Thanks in advance, > Matt. > > > == This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == 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: WMQ 5.3 runmqtrm failure
Terry, We ran into similar problems. In our case, our JAVA AIX application was hanging and taking up resources while triggering but it was running fine from command prompt. What kind of application are you running? Is it JAVA or something else. We solved our problem by including "export JAVA_COMPILER=NONE" in our script before calling our application. CSD04 should also resolve this problem. Thank You Lail S. Hossain MQseries/DRF Administration and Support PepsiCo Business Solutions Group -Original Message- From: Terrence J Serena [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 8:35 AM To: [EMAIL PROTECTED] Subject: WMQ 5.3 runmqtrm failure I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry 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
Risks of implementing Single Write Integrity
RE: Risks of implementing Single Write Integrity > Solaris 5.8 > MQ 5.2 CSD7 > > We are having some performance issues on our Queue managers lately and I was considering moving from Triple to Single Write Integrity. All disks are on an EMC SAN so I assume this is exactly the sort of situation that the Single Write Integrity option was designed for. > > Does anybody have any experience of this? I am interested in hearing about the possible performance improvements and the risks of moving from Triple to Single Write Integrity. > > Thanks in advance, > Matt. > > > == This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. CREDIT SUISSE GROUP and each legal entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. == 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: WMQ 5.3 runmqtrm failure
Are the programs written in Java?If they are, there are some Apars that relate to problems with runmqtrm and V5.3. Jim Terrence J SerenaTo: [EMAIL PROTECTED] <[EMAIL PROTECTED]>cc: Sent by: MQSeries List Subject: WMQ 5.3 runmqtrm failure <[EMAIL PROTECTED]> 09/24/2003 08:34 AM Please respond to MQSeries List I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry 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: WMQ 5.3 runmqtrm failure
Terry, I wouldn't accept that as an answer. Did they at least ask for a trace? Terrence J Serena To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: >Subject: WMQ 5.3 runmqtrm failure Sent by: MQSeries List <[EMAIL PROTECTED] en.AC.AT> 09/24/2003 09:34 AM Please respond to MQSeries List I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry 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
MQ 5.2: New code pages
Title: MQ 5.2: New code pages Hello, I'm currently migrating my mainframe MQ subsystems from Version 2.1 to Version 5.3 (skipping 5.2). In reviewing the Version 5.2 System Setup Guide, it mentions new code pages being added, including one for Unicode. Does anyone have these documented ? Thanks in advance, Judy Yeske
WMQ 5.3 runmqtrm failure
I have just upgraded to WMQ/AIX 5.3. Since the upgrade, any programs triggered from runmqtrm are failing. The failing programs do the following: Connect to the QMGR Open a local queue Connect to the local database (Oracle) Get messages off the queue Insert data into database Close queue Disconnect from QMGR The failure occurs in the connect to the database. The error message says an incorrect username and password is being used. The database has been ruled out as the culprit. An interesting point; if I enter the values from the Process definition's APPLICID manually from a Command Prompt, the program successfully executes. It just fails when triggered through runmqtrm. Nothing has changed in the programs being triggered. We run runmqtrm as it comes from IBM, with no variations. All programs that are triggered are failing since the upgrade. If I back off to MQ 5.2 everything works fine. I opened a PMR with IBM, they say; "Few things are changed between MQ 5.2 and MQ 5.3 in the area of signal handling. We have seen this causes trouble for some applications triggered by trigger monitor. This needs to be diagnosed by application programmer." Has anyone run into a similar problem when upgrading to WMQ 5.3? Thanks, Terry 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: Euro symbol and WMQI
Thanks for yours responses. I change the qmgr CCSID to 858 and it fixed my problem. Thanks again > -Mensaje original- > De: Kulbir S. Thind [SMTP:[EMAIL PROTECTED] > Enviado el: Tuesday, September 23, 2003 17:07 > Para: [EMAIL PROTECTED] > Asunto: Re: Euro symbol and WMQI > > > What platform are you using and what code page is configured for the queue > manager. We have successfully managed to use the Euro as long as we used > the correct code page. We were on Windows and changed our default code > page of 850 to 858 and it worked ok. You just need to make sure that all > the code pages in your system are configured to be able to support the > Euro, this may be a bigger issue, it was for us. We couldn't go to 300+ > end points and change the code pages without doing extensive testing, in > the end we avoided using the Symbol. > > Hope this helps. > > > > ""Rodríguez Alvarez-Querol, Manuel Carlos"" <[EMAIL PROTECTED]> > > Sent by: "MQSeries List" <[EMAIL PROTECTED]> > > 23-Sep-2003 12:09 > Please respond to "MQSeries List" <[EMAIL PROTECTED]> > > > > To:MQSERIES > > cc: > Subject:Euro symbol and WMQI > > > > I have an xml which contain the euro symbol, EUR, and I can´t parse the > xml. > I created a message flow with MQInput and trace node and don´t get the > euro > symbol in my trace file. > > I have WMQI 2.1 CSD2 and MQ5.2 CSD4. > > Any clue? > > Thanks, > > 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
