If the msg is string format, the channel should convert it. You do have to
stop/start the channel if it is running when you change the conversion
option.
-Original Message-
From: Dawson, John [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 10:41 AM
To: [EMAIL PROTECTED]
One of the prerequisites for trigging is that a trigger monitor must have
the initiation queue open for input. This is likely the reason.
-Original Message-
From: MCSHEFFREY, MICHELLE (AIT) [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 25, 2002 12:38 PM
To: [EMAIL PROTECTED]
According to the description of the reason code, this can happen if your
logs aren't large enough to support the unit of work. How large are you're
logs? circular or linear?
-Original Message-
From: Alessandro Caffarra [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 7:06 AM
The default on OS390 is 3 which is the combination of 1 (match msg id) and 2
(match correlid), so adding 2 more gives 5 which is 4 (match group id) and 1
(match msg id), I think. Anyway, you're original code of moving MQMO-NONE
(0) and then adding MQMO-MATCH-CORREL-ID (2) should have given you
Title: Waitinterval and response time of CICS transaction
I
think this may be because the default on OS390 (if not otherwise specified) is
that puts are done in syncpoint. I've seen this problem before. The
program issues a put not knowing that it is within syncpoint and then waits for
a reply.
If you want to see your posts you need to send the message SET MQSERIES
REPRO to [EMAIL PROTECTED] -- not the mqseries listserver address.
Your messages have been reaching the listserver.
You may leave the list at any time by sending a SIGNOFF MQSERIES
command to [EMAIL PROTECTED] You can
Title: RE: NT/2k: trigger monitor stalls in batch window, need Enter key.
I run
the trigger monitor using the MQ Explorer Services. I'm using it for the
DLQ handler program and it's been working fine. Nick
-Original Message-From: Benjamin Zhou
[mailto:[EMAIL PROTECTED]]Sent: Monday,
Title: RE: NT/2k: trigger monitor stalls in batch window, need Enter key .
Just
curious. Is this somehow a better way to install a trigger monitor than by
right clickingon the qmgr in the Services Explorer and selecting
new/trigger monitor?
-Original Message-From: DeFreitas, Nigel
Now
that I look at it, no. It appears they are just unique strings (letters
numbers).
-Original Message-From: Tony Reddiough
[mailto:[EMAIL PROTECTED]]Sent: Thursday, October 17,
2002 12:36 AMTo: [EMAIL PROTECTED]Subject: Re:
Dynamic Queue Names
I
don't think so,
I'm not sure if it has changed since I'm still using
v5.2. But remember that if the DynamicQueueName of the MQOD is not
terminated with an asterisk, then the unique portion of the name will not be
generated. Could an application be doing this
inadvertently?
-Original Message-From:
Are you using one amqclchl.tab for all your qmgrs, new and existing? If so,
you should be able to update the connection name for these existing qmgrs
and re-export the channel table.
-Original Message-
From: Joshi, A (Anant) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 17, 2002
This is a known problem which is supposed to be fixed by CSD05. You can
find the description in the summary of changes for the CSD. I think the
real problem is that the error logs are not rolling over properly because of
an authority issue. Check your error logs for the queue manager and see
The reply could also be lost anywhere along the route if the expiry time has
been exhausted. Is this a possibility?
-Original Message-
From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 14, 2002 10:02 AM
To: [EMAIL PROTECTED]
Subject: Lost MQ message
I've never yet had to rollback a CSD, but I need to test the procedure to
estimate the time. What is the procedure for rolling back to a previous
CSD. The CSD creates a directory for this purpose, but using the deinst.exe
in the temp install directory directs me to use the add/remove programs
The backout count only applies for messages that are backed out within a
unit of work, explicitly or through an abend. So, in the case described,
even if the MQBACK command were issued, it would be a NO OP since the get
was done with No-syncpoint.
Even if the get was done with syncpoint and then
The
default syncpoint option on OS390 is to use syncpoint. The default on
distributed platforms is to not use syncpoint. If you are using the
default, perhaps your put and get on OS390 are operating in the same
syncpoint. Thus the reply never returns because the message is never put
(i.e. you
Could it be missing one of the other required pieces such as MMC, or does it
specifically indicate the server version? There is a directory on the disk
which contains some of the prerequisites.
Nick
-Original Message-
From: Bruce Baxter [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15,
You can put a message to the SYSTEM.COMMAND.INPUT queue (assuming your
program has the authority). DISPLAY QUEUE(MYQUEUE)CURDEPTH is the command.
You have to specify a reply to q and qmgr. Then you get the reply messages
and check the depth. I believe three messages are returned and the
I
encountered the same problem with our exitwhen I installed MQ 5.2 without
uninstalling version 5.1. I was using CSD3 with an efix at the time.
I uninstalled and uninstalled completely and reinstalled 5.2 and the problem
disappeared. I opened a PMR with IBM but closed it when I resolved the
Additionally, if you want to know the object for which the 2035 message
was issued, look on the appropriate error log for the qmgr and there should be a
corresponding 8077 message which specifies the object name.
-Original Message-From: Alessandro Brezzi
[mailto:[EMAIL
Lakshmi,
I think you're assuming that QM1 leaves the ReplyToQMgrName blank and that
QM2 will see it is blank and default to QM2. This is not the way it works.
According to the APR, QM1 looks to see if it has a remote queue named
QM2.REMOTE.QUEUE and if so uses that qmgr name otherwise it uses
Are you sure the discint is 6000 (that's 100 minutes by the way)? Could
some transaction be trigger the channel and then be backed out? This still
doesn't explain why the channel didn't stay running, does it?
-Original Message-
From: Jeff A Tressler [mailto:[EMAIL PROTECTED]]
Sent:
How are you connecting to the qmgr -- via a amqclchl.tab or via the mqserver
environment variable? It sounds like you have a problem connecting to the
qmgr. Can you open a DOS window and do an amqsputc to a test queue?
-Original Message-
From: ashish baby [mailto:[EMAIL PROTECTED]]
You could also use support pac MO71.
-Original Message-
From: Robert Broderick [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 17, 2002 5:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Remote Admin
A limitation on the OS390 platform is it does not accept PCF commands.
Therefore there is a need
24 matches
Mail list logo
